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(54) Cbjed-oriented system, mettiod and article of manufature for a dient-server event dnver^ 
message framework in an interprlse computing framework system _ 



(57) An interprise computing manager in which an 
applicaticn is composed of a client (front erKi) program 
which communicates utilizing a network wnth a server 
(k>ack end) program. The client and server programs are 
loosely coupled arxl exchange information using the 
network. Ihe client program is composed of a User 
Interface (Ul) and an object-oriented franriework (Pres- 
entation Engine (PE) frameworl^. The Ul exchanges 
data messages with the framework. The framework is 
designed to harvJIe two types of messages: (1 ) from the 
UL and (2) from the server (back end) program via the 
network. The franiework includes a component, the 
mediator which manages messages coming into and 
going out of the framework. The system includes 
ware for a client computer, a sender computer and a net- 
work for connecting the client computer to the server 
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computer which utilize an execution framework code 
segment configured to coiple the server computer and 
the client computer via the network, by a pluralu/ of cli- 
ent computer code segments resident on the server, - 
each for transmission over the network to a client com- 
puter to initiate coupling; and a plurality of server com- 
puter code segments resklent on the server which 
execute on the server in response to initiation of cou- 
pling via the network with a particular client utilizing the 
transn^ed dient computer code segment for communi- 
cating via a particular commurvcation protocol. A medi- 
ator state machine is utilized to parse various message 
types and route the messages to appropriate parts of 
the execution framework for further processing. 
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Description 

COPYRIGHT NOTIFICATION 

5 Portions of this patent application contain nnateriate that are subject to copyright protection. The copyright owner 
has no objection to the facsimile reproduction by anyone of the patent docunrtent or the patent disclosure, as it appears 
In the Patent and Trademark OfTice. 

Rdd of the Im^ention 

10 

This invention generally relates to improvements in computer systen^ and. more particularly, to operating system 
software for managing Interprise computing in a network user interfaca 

Background of the Invention 

15 

One of the most important aspects of a modern conr^xiting system is the interface between the human user and 
the machina Ttie eariiest arxi vnosX popular type of interface was text based; a user conrtmunicated with the machine 
by tyfxr^ text characters on a keyboard and the machine communicated with the user by displaying text characters on 
a display saeen. More recently, graphrc user Interfaces have t)econrfe popular where the machine communicates witii 
20 a user by cfisplaying graphics, including text and pictures, on a display screen and the user comnumicates with the 
machine both by typing In textual commands and by marvpulating the displayed pictures with a pCHnting devk:e. such as 
a mouse. 

Many nradern oonrputer systems operate with a graphk: user interfece called a window environmerrt. In a typkal 
window environment the graphical cfisplay portrayed on the display screen is arranged to resemble the surface of an 

25 electronic "desktop" and each applicatkm program running on the computer is represented as one or nrx>re elecbronk: 
"paper sheets'* displayed in rectangular regk)ns of tiie screen called \irindo^ 

Each window regk>n generally displays Inforntation which is generated by tfie associated applk^ation program and 
there may be several wirxtow regk>ns simuttaneousty present on the desktop^ each representing Information generated 
by a cfifferent application program. An application program presents information to the user through each window by 

30 drawing or "painting" images. graphk;s or text within the window regkxi. The user, in turn, communk^es with the appli- 
cation t>y "pointing at" objects in the wirxkTw region with a cursor which is controlled by a pointing device arxl man^- 
lating or nDoving the objects and also by typing information into the keytx)ard. The window regk>ns may also be nrxsved 
around on the display screen and changed in size and appearance so that the user can arrange the desktop in a con- 
venient manr^r. 

35 Each of tiie window regk)ns also typically includes a nurTt>er of standard graphical otsjects such as sizing boxes, 
buttons arxl scroll t>ars. These features represent user interface devk^es that the user can point at with the cursor to 
select and manipulate. When the devices are selected or manipulated, the underiying applk^ation program is informed, 
via tiie window system, that the control has been manipulated by the user. 

In general, the window environment described atxve is part of the computer operating system. The operating sys- 

40 tern also typically indudes a cdlection of utility progranris that er^e thecoma 

such as storing and retrieving information on a disc memory, communicating with a networic and performing file opera- 
tions including the creation, narrung and renaming of files and. in some cases, perfbmiing diagnostic operations In order 
to discover or recover from malfunctions. 

The last part of the conrputing system is tiie "application program" whk:h interacts with the operating system to pro- 

45 vide much higher level functionality, perform a spectfic task and provkle a direct interface with the user. The appik^ation 
program typk^ally makes use of operating system functions tsy sending out series of task commands to the operating 
system which then performs a requested task. For example, the application program may request tiiat the operating 
system store particular information on the computer disc memory or display Information on the vkJeo display. 

Figure 1 is a schematic illustration of a typical prior art computer system utilizing both an applk:ation program and 

so an operating system. The computer system is schematically represented by box 1 00. the application is represented by 
box 102 and the operating system t>y box 106. The previously-descri>ed Interaction between the application program 
1 02 and tiie operating system 1 06 is ill ustrated schematically by arrow 1 04. This dual program system is used on maxxf 
types of corriputer systenris ranging from nriain franfie^ 

The method for handling screen displ^ varies from computer to computer and. in this regard. Rgure 1 represents 

55 a prior art personal corrputer system. In order to provkie screen displays. applk:ation program 102 generally stores 
information to be displayed (the storing operation is shown schematically by arrow 108) into a saeen buffer 110. Under 
control of various hardware and software in the system the contentsoftite screen buffer 110 are read out of the buffer 
and provkied. as inc£cated schematically by arrow 114, to a display adapter 112. The cGsplay adapter 112 contains 
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hardware and software (sometimes in the fam of firmware) which converts the information in screen buffer 1 1 0 to a 
fam wfich can be used to drive the display monitor 118 which is conned 

TTte prior art configuration shown in Figure 1 generally works well in a system where a single application program 
1 02 is running at any given tima This sin^e system worte property because the single application program 1 02 can 

5 write infonnation into any area of the entire screen buffer area 110 without causing a display problem. However, if the 
configuration shown in Figure 1 is used in a computer system where more than one application program 102 can be 
operational at the same time (for exanple. a "multi-tasking'' computer system) display problenrts can arise. More partic- 
ulariy. if each appficatk)n program has access to the entire saeen buffer 1 1 0, in the absence of some direct communi- 
cation between applications, one application may ovenwrite a pwtion of the screen buffer whch is being used by 

10 another applicatwn, thereby causing the cfisplay generated by one application to be ovenwritten by the display gener- 
ated by the other application. 

Accordingly, mechanisms were devetoped to coorCfinale the operation of the applrcation programs to ensure that 
each application program was confined to wly a portion of the screen buffer thereby separating the other displays. This 
coordination became complicated in systems where windows were alkr*ed to "cveriap" on the screen dsplay. When 

IS the saeen display is ananged so that windows appear to "overiap^ a window which appe^ 

another window covere and obscures part of the undertying window. Thus, except fx the fbrenriosl window, onh^ 
the underiying windows may be drawn on the saeen and be "Vistole" at any gpven 'jme. Further, because the windows 
can be moved or resized by the user, the portion of each window which is visible changes as other windows are moved 
or resized. Thus, the portion of the screen buffer wrtch is assigned to oach application window also changes as win- 

20 dows from ether applrcations are moved or resized. ^ 
In Older to eff identiy manage the changes to the saeenjxiffer necessary to accommodate rapid saeen changes 
caused by moving or resizing windows, the prior art computer arrangement shown in Rgure 1 was modified as shown 
in Rgure 2. In this new arrangement computer system 200 is controlled by one or more apfrfication programs, of which 
programs 202 and 21 6 are shown, which programs may be running simuftaneousiy in the computer system. Each of the 

25 programs interfaces with the operating system 204-as^31istrated scheiiiaScally t>y anows 206 and 220. However, in 
order to display information on the display saeeorsppliration programs 202 and 216 send display information to a cen- 
tral window manager program 218 located in the operating system 204. The window manager program 218, in turn, 
interfaces directly with the saeen buffer 210 as illustrated schematically by arrow 208. The contents of screen buffer 
210 are provided, as indicated by arrow 212. to a dispfay adapter 214 wh:c^ 

30 monitor 224. . . . 

In such a system, the window manager 218 is generally responsWe foi maintaining all of the window displays that 
the user views during operation of the application programs. Since the window n-anager 218 is in communication with 
all application programs, it can coordinate between applications to insure that window displays do not overiap. Conse- 
quentiy, it is generally the task of the window manager io keep track of the tocalfon and size of the window and the win- 

35 dow areas which niust be drawn and rectawn as windows are iTK^ 

The window rianager 218 recwes display requests from each of t^^ applications 202 and 216. However, since 
only the window manager 21 8 interfaces witfi the screen buffer 21 0. it can allocate respective areas of the screen buffer 
210 for each applicatkxi and insure that no application erroneously ovenwites the dsplay generated by another appli- 
cation. There are a nunfoer of different window environnr>enls commercially awaifable which utilize the arrangement fllus- 

40 trated in Rgure 2. These include the X/Window Operating environment, the WINDOWS- graphical user Interface 
devefoped l>y the Mkrosofl Corporation and the OS/2 Presentation Manager developed by the International Business 
Machines Corporation, and the Macintosh OS, devetoped by Apple Computer Corporation. 

Each of these window environments has its own internal software architecture, but the architectures can all be clas- 
sified by using a multi-layer model simifar to the mutti-layer nKJdels used to describe computer networi^ software. A typ- 

45 ical nrutti-layer nxxJel includes the folfowing fayers: 

User Interface 
Window Manager 

Resource Control and Communication 
so Component Driver Software 
Computer Hardware 

where the tenn Nvindow environnrienr refers to all of the above layers taken together. 

The towest or conputer hardware level includes the basto computer and associated input and output devices 
55 including display monitors, keyboards, pointing devtoes, such as mtoe or trackballs, and other standard components, 
including printers and disc drives. The next or "component driver software" level consists of devtoe^ependent software 
that generates the connands and signals necessary to operate the various hardware components. The resource con- 
trol and coimiunfcation lay©- interfaces with the component drivers and includes software routines wtnch altocale 
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resources, coimunicate beNveen appOcalions and multiplex communicatjons generated by the Iwgher layers to the 
underlying layers. The window manager handles the user interface to basic window operations, such as mcving and 
resizing windows, activating or inactivating windows and redrawing and repainting windows. TTie final user interface 
layer provides high level facflities that implement the various controls (buttons, sliders, boxes and other controte) that 
application programs use to develop a conplete user interface. 

Although the anangement shown in Figure 2 solves the display saeen interference problem, it suffers from the 
drawback that the window manager 218 must process the screen display reciuests generated by all of the application 
programs. Since the requests can only be processed serially, the requests are queued for presentation to the window 
manager before each request is processed to generate a display on temtinal 224. In a display where many vwndows are 
present simultaneously on the screen, the window manager 218 can easily become a "bottleneck" for cfisplay inforra- 
tion and prevent rapid changes by of the dfeplay by the application programs 202 and 21 6. A delay in the redrawing of 
the screen when windows are moved or repositioned by the user often manifests i^ 

ctows are being constructed in a paecemea! fashion which becomes annoying and detracts from the operation of the sys- 
tem. 

This problem becomes even more accentuated in a client-server environment where many applications are all in 
contention for very Rmrted resources. The Internet has permeated the workplace as a communication medium of 
chowa Since the intanct is accessWe from almost any point in a typcal kxisiness enterprise a new buzzword has 
evolved from the form enterprise computer into an Interprise" computer. Interprise a concatenation of internet and 
errterprise. 

In today's dient sender enterprises, applications that exist in current dient sewer enterprises are not really built to 
-be.managedsinc**ihey are^chitected for (fislrtouted system environments. New systems are also requred to be evo-^ 
lulionary, not revolutionary. Redesign of current systems that require signif icant expense need to be avoided. 

A system is required that allows a user to create managesdWe applications, that can be readily d^oyed. installed 
on a variety of platforms, and conf igured to fadlitate partitioning them on dients versus servers and administer the 
'applications once they're nmning. Systems dont always break because of failure, errors, or bugs, they som^mes ^ 
break because enterprise Itself is compficaled and somebody does something unexpected somewhere whi^j^ 
bring the whole system down. When the system does conrw down, then a system administrator must be able to readily 
klentify the problOTs, and deal with them in an effective manner so that a business doesnt stop functfoning when one 
of these unforeseen events happens. 

- - T^3 appl'ica^on shcuW be designed based on domain requirements, so it is independent of any platfomi under- 
neath, and fits more wilh hew commercial devetopers work. In the commercial worid. the devetopment process isnl that 
inportarrt. The regular enptoyees are not applications developers or programmers. Companies usually hire such worit 
out tiw get consultants to do that kind of worie Depending on the company and wrhat ttiey want done, it usually hires 
& conuiting firm, indivWual consultants, or smaller groups of consultants to come in, help it develop an appfication. 
Their goal is the end appfication, which must be maintained. The company configures it, evolves it and grows it To 
allow for modification, the devetopment task must be modular to altow different groups of people woridng on different 
parts of an appfication, without requiring any one group to understand every detail of the whole appfication of the enter- 
prisa 

The second criterion requires minimal extra knowledge, burden or sophistication on the part of the people devetop- 
ing the system. Most conpanies do not desire to have their business hinge on a single individual. Rather, they desire 
to have people who are primarily domain experts.who can work with well-underslood tools to produce a application 
matchi;^ company requirements qukMy without making special demands on the corrpany. 

Sunmiary off the Invention 

The foregoing problems are overcome in an illi^lrative embodiment of the invention in which an application is com- 
posed of a dient (front end) program which oommuracates utilizing a networi^ with a sender (back end) program. The 
dient and server programs are loosely coipled and exchange information using the networtt The dient program is 
conposed off a User Interface (Ul) and an objedH)riented framewori^ (Presentation Engine (PE) frameworl^. The Ul 
exchanges data messages with the framework. The framewori^ is designed to handle two types off messages: (1) from 
the Ut and p) from the server (bade end) program via the network The franr)^^ 
whk:h manages messages coming into and going out of the framework. 

A(fistributed conputer system is disdosed with software for a cCent conputer, a server conp^ 
for connecting the diertcomputertotheserverconpulerwhfch utilize an execution franr)eworic^ 
ured to couple the server conputer and the cfient computer via the networi<, by a pluraTrty off dient computer code seg- 
ments resklent on the server, eadi for transmission over the networic to a dient computer to initiate coupling; and a 
plurality off sewer conputer code segnrients resklent on the server whfch execute on the server in response to initiation 
off cotplmg via the networic with a particular dient utffizing the transmitted dient conputer code segment for comnwi- 
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eating via a particular comimnicalion protocol . A mediator state machine is utilized to parse various message types 
and route the messages to appropriate parts of the execution framework for further processing. The presentation 
engine manages message processing utilizing the presentation en^ne framework and the user interface. 

Brief Description of the Drawings 

The above and further advantages of the invention may be better understood by refening to the fr)llowing descrip- 
tion in conjunction with the accompanying drawings, in which: 

Figure 1 is a schematic bk)ck diagram of a prior art computer system showing the relationship of the application 
program, the operating system, the screen buffer and, the display nrwnitor; , 

Figure 2 is a schematic block dagram of a modification of the pria art system shown in Figure 1 which allows sev- 
eral application programs running simultaneously to generate screen displays; 

Figure 3 is a block schematic diagram of a computer system for example, a personal computer system on which 
the inventive object oriented window manager operates: 

Figure 4 is a block dic^ram in accordance with a preferred embodiment; 

Figure 5 illustrates how a preferred embodiment leverages Java to fadrrtatethie esteWishmenlapd jmplOTertation 
of se^er-centrfo policies; 

Figure 6 illusfrates the processing associated with application startup in accordance with a pr^erred embodiment: 

Figure 7 illustrates the three fundanriental components of an application in a^x)rdance wrti^a prefen^ed embodi- 
ment; 

Figure 8 illustrates the migration of an existing dient-sen^er ^ication toone supported by a preferred embodi- 
ment; , 

Figure 9 is a btock diagram illustrating a PE 960 in accordance with a preferred smbodinrient; 

Figure 10 is a block diagram of a pria art dient server architecture in axordarice with a pr^ed embodiment; 

Figure 1 1 illustrates an application in accordance with an alternate embodiment; 

Figure 12 illustrates a server 1 21 0 establishing contact with a dient 1 200 in accordance with an alternate embocfi- 
ment; 

Figure 13 fliuslrates a loosely coupled dient - server application in accordance with an alternate embodiment; 

Figure 14 illustrates the system integration task necessary to devetop an application 1430 in axwrdance with a pre- 
ferred enrtxxJimern; 

Figure 15 is a block diagram illustrating the modular design of a dient application in accordance with a pr^erred 
embodiment; 

Figure 16 is a block diagram of a frameworic in accordance with an alternate embodiment; 

Figure 17 illustrates the basic building btocks in accordance with an alternate embodiment; 

Figure 18 is a block dis^ram highlighting the steps utilized to extend the framework m accordance with a preferred 
embodiment; 

Figure 19 is an illustration of a PE Object in accordance witti a preferred embocfiment; 
Figure 20 is an Illustration of a PE Evert Handler 2000 used by N^ews to hande incon^ 
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in accordance wfth a preferred embocfim^ 

Figure 21 Olustrates a PEtnfb object 21 00 data in accordance with a preferred entxxfiment; 

Rgure 22 illustrates Inconrting message flow to a nrxxJel in accordance with a preferred entxxJiment; 

Figure 23 illustrates inconrang niessages mapping a Ul to a Model in accordance with a preferred embodiment; 

Figure 24 fliustrates outgoing messages mapping a nrxxlel to messages in accordance with a preferred embodi- 
ment; 

Figure 25 illustrates outgoing messages mapping a model to a Ul in accordance with a preferred emtodiment; 

Figure 26 illustrates the steps associated with launching an application URL in accordance with a prefenred embod- 
iment; 

Figure 27 describes the forms of a Presentation Engine, as an abstract Java dass. a template for development and 
an executable component in an application in acoordarTce with a preferred embodiment; 

Figure 28 descrtoes the fundfons developers nmjst fill In using the server program template in accordance with a 
preferred embodiment; — ^ ' 

Figure 29 illustrates Server Properties in accordance with a preferred errtxxliment; and 
Figure 30 is a table of dienl and serverxKle-exceptions.in accordance with a preferred embodiment. 
Detailed Description 

The invention is preferably practiced irUhe contact of an cperaling system resident on a computer such as a SUN, 
IBM- PS/2" or Apple* Macintosh' computefc A.represer^/e hardware environment is dejMcted in Rgure 3, which illus- 
trates a typical hardware configuration of a conrtputer 300 accorcian^ invention. The computer 300 
is controlled by a central processing unit 302 (which ma> be a conventional microprocessor) and a number of other 
units, all interconnected via a system bus 308. are provided to accomfriish specific tasks. Although a particular compu- 
ter may only have some of the units fllusirated in Rgure 3, or may have additional components not shown, most com- 
puters will include at least the units shewn. 

SpedTicalty. coriputer 300 shown in Rgure 3 indudes a random access men«^ 
of infbrmalioa a read only memory (FOM) 304 for perrnanent storage of the computer 

ating commands and an irput^output (I/O) adapter 31 0 for connecting peripheral devices such as a disk unit 31 3 and 
printer 314 to the bus 308. via cables 31 5 and 312, respectively. A user interface adapter 31 6 is also provided for con- 
necting input devices, such as a keyboard 320. and other known interface devices induding trace, speakers and ntoo- 
phones to the bus 308. Visual output is provided l>y a display adapter 318 which connects the bus 308 to a display 
devk» 322. such as a video rnorto. The conrputer has residert thereon and 
system software such as the SUN Solaris or JavaOS operating system. 

In a preferred embodiment, the invention is in^emented in the C++ programming fanguage using ot^ ect-oriented 
programming techniques. C++ is a compned language, that is. programs are written in a human-read^e scr^ and this 
scriJt is then provided to another program called a compiler which generates a machine-readable numeric code that 
can be loaded into, and directly executed by. a computer. As descn^bed below, the C++ language has certain character- 
fetics whkrft allow a software devetoper to easily use progranis writ^ 

trol over the reuse of programs to prevent their destruction or improper usa The C++ language is well-known and many 
artides and texts are available which describe the language in detail. In addition. C++ compilers are commercially avail- 
able from several vendors mduding Bortand Intennatkxial, Ina and Microsoft Corporatfon. Accordingly, for reasons of 
darily, the details of the Cf + language and the operation of the C++ compiler win not be dscussed further in detail 
her^n. 

As will be understood by those skiHed in the art Cfcject-Oriented Programming (OOP) techniques involve the defi- 
nition, creation, use and destruction of "objects". These objects are software entities comprising data elements and rou- 
tines, or functions, which manipulale the data elements. The data and related functions are treated by ttie software as 
an entity and can be aeated, used and deleted as if they v»«re a single itern. Together, tt^^ enable 
objects to modd virtuafly any real-worid entity in tenns of its charaderistics, wh^ 
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merits. arxJilsbehasw. which can be represent m this way. objects can mode! 

concrete things like people and conputers. and they can also model abstract concepts like numbers or geometncal 
designs. 

Greets are defined by aeating "dasses* which are not ot^ecls themselves, but which act as templates that nfistru;t 

5 the conpiler how to constmct the actual object A class may. for example, spec^ 

and the steps involved in the functions which nrwiipulate the data. An object is actually created in the program by 
means of a special function called a constmctor which uses the corresponding dass definition and aJditk>nal infomia- 
tion. such as arguments provided during object aeation. to construct the object Ukewise ol^ecls are destroyed by a 
special function called a destructor. Objects may be used l>y using their data and invoking their functions. 

10 The principle b^^nef its of object-oriented frogramming techniques arise out of three basic prindples; encapsulatron. 
polymwphism and inheritance. More specifk;ally, objects can be designed to hide, or encapsulate, all. or a portion of. 
the intsmal data structure and the internal functions. More particularly, during program design, a program developer 
can define objects in which all or some of the data variables and all or some of the related functions are conskJered >i- 
vate" or for use only by theobject itself. Other data or functkxis can be declared >iblic" or available for use by other 

15 programs. Access to the private variables by other programs can be controlled by defining public functfons for an ot^ect 
which access the objecTs private data. The pubfic functions fbrnn a contrdled and consistent interface between the pri- 
vate data and the "cjiside'' worid. Any attempt to write program code whkrfi cfirectly accesses the private variables 
causes the conpiler to generate an enor during program compilatfon which error stops the compilation process and 
prevents the progi am from being run. 

20 Polymorphism is a concept whkil allows Objects and funclfonswhi* 

v/ith different data to funclfon <fifferentty in order to produce consistent results. For example, an addition function ma^ 
be defined as variable A plus variable B (A+B) and this same fbnrot can be used whet^ 

characters or ddlars and cents. However, the actual program code whk:h performs the addition may differ widely 
depencfing on the ^,^>e of variables that comprise A and a Polymorphism altows three separate function definitions to 
^ 25- bG;vrillsn. one foi^ecich type of variable {numbers, characters and ddlars). After the functions have been defined. a^MO: 

gram can later i efer to the addition function by its common for^ « 
detem^ne whfch of the three functions is actually being used Ijy examirting the variable types. The compiler will then 
sitetitute the prcapor function code. Polymorphism allows similar functions which produce analogous resdts to be 
"grouped" in tiie pru^am source code to prochK^e a nrwre lospcal and d^ 

30 - The third prindple Which underfiesobjedK)riertedprogranm™ 

- to easily reuse jM^e-existing programs and to avdd aeating softwvare from scratch. The princ^rie of inheritance altows a 
software devetoper to declare classes (and the objects which are later aeated from them) as related. SpedrTcally, 
classo& may be designated as subdasses of other base classes. A subdass "inherits" and h^ 
Ifc functions of Its base classes just as if these function appeared in the subdass. M 

35 some or aK Of its inherited functions a may nrxxlify some or all Of its inherited ft^^ 
tion with the sarne form (overriding or modiTra^^ 

use of the function inthesiixdass).Theaeationoffanewsubdassvirhichhassomeofthefunctiona^^ 
modfffcation) of another dass alkws software developers to easily cuslonuze existing code to meet their parbaJar 
needs. 

40 Although objectKJriented pro^amming offers significant improvements over other programing concepts, program 
devetopmert still requires significant outtays of time and effort especially if 
able for modification. Consequentty. a prior art approach has been to pro^ 

defined, interconneded classes wtwch aeate a set of objects and acWitional miscellaneous routines that are all directed 
to perfomiing commor^y-encountered tasks in a particular environment Such prfr<Jefined classes and libranes are typ- 

45 ically called "frameworics" and essentially provide a prefabricated structure for a woridng applwation. 

For exarrple, a fraineworic for a user interface might provkl interface ejects whkrfi 

create windows, scrdi bars, menus, eta and provkJe the support and ^default" behavfor for these graphfc interface 
objects. Since framewori© are based on ot^ect-oriented technk^ues. the predefined classes can be used as base 
dasses and the buiH-in default behavfor can be inherited by developer-d^ined subdasses and either modified or over- 

50 ridden to altow devetopers to extend the frameworic and aeate custontized solutions in a particular area of expertise. 
TTiiso^ed-oriertedwroachpiwktesanri^radvant^ since the programmer is not 

changing the original program, birt rather extending the capabflities of the origin 

not blindly woridng through layers of code because the frameworic provkJes architectural guWance and modding and, 
at the same time, frees the devdopers to s^pply specific actfons unk?ue to tiie problem 
55 There are many kinds of framewort® awanaUe, depending on the level of the system involved and the kind of prob- 
lem tobe solved. Thetypesofframewori© range from high-level appTication framewori® that assist in devetoping a user 
interface, to tower-levd frameworis that provWe bask: system software senrices such as communfcations. printing, f«e 
systems support graphtes, etc. Commerdal exampies of appDcation frameworks indud^ MacApp (Apple), Bedrodc^ 
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(Symantec). OWL (Borland). NeXT Step App Kit (NeXT). and Smalltalk^ MVC (ParcPIace). 

While the framework approach utilizes all the princiFrfes of encapsulation, polymorphism, and inheritarK» in the 
object layer, and is a substantial inrprovement over other programming techraques. there are cfifficulties which arise. 
Appticatkxi framewwte generaDy consist of oie a more object "layers- on top of a monoDthk: opiating system and 
5 even with the flexibnity of the object layer, it is still often necessary to directly interact with the underlying operabng sys- 
tem by means of awkward procedural calls. 

In the same way that an application framework provides the devetoper with prefab functionality for an application 
program, a system framework, such as that included in a preferred embocfiment can provide a prefab functionality for 
system level servfces which devetopers can modify or override to aeate customized colutions, thereby avoiding the 
70 awkward procedural calls necessary with the prior art application frameworks programs. For exarrple. consider a ds- 
play framework which could provide the ftxjndation for creating, deleting and manipiilating windows to display infeMina- 
tion generated by an ^icatkxi program. An application software developer who needed these capabilities would 
ordnarily have to write specific routines to provide them To do this with a needs to sup- 

ply the characteristics and t>ehavior of the finished display, while the framework provides the actual routines which per- 
is formthetasks. 

A preferred entxxliment takes the concept of frameworks and applies it throughout the entire system, inducing the 
applk:ation and the operating system For the convnerdal or corporate devetoper. systems integrator, or OEM, this 
means all of the advantages that have been illustrated to a franr^ework such as MacApp can be leveraged riot o^^^ 
the application level for such things as text and user irterfaces, but also at the system level, for sen^ 

20 ing, graphics, multi-media, fSe systems. I/O, testing, eta 

A preferred entxxJiment is written using JAVA. C. and the C++ language and utijL;^ ot^ eel <went^ progranwing 
methodology. Object oriented progranrvrong (OOP) has become inaeasingly used to devetop conr^ex appfications. As 
OOP moves toward the mainstream of software design and development, various software solutions require ad^rtation 
to make use of the benrfits off OOP. A need odsts for tiiese principles of OOP to be applied to a messaging interface of 

25 an electronic messaging system such that a set of OOP classes and objecte for th^rne^ging interface can be pro- 
vided. 

OOP is a process of devetoping computer software using objects, including the steps of analyzing the problem, 
designing the system, and constructing the program. An ot^ect is a software pa^^ 

lectkxi of related structure, and procedures. Since it contains both date and a coll€K;tion of stmctures and procedures. 

30 it can be vtsuaTized as a s^-suTident component that does not require other ^■itk)n^ str\K:tures, proa^ or date 
toperfomi its spedfic task. OOP. therefore, views a computer program as a collection of largely autonoincus conpo- 
nenls, called objects, each off whwh is responsible for a spedfic task Tliis concept of packaging data, stmctures, and 
procedures togeth^ in one cornponent or niodule IS called ericapsulation. 

In general. OOP components are reusable software modules which present an interface tiiat confonns p an ol)ject 

3S model and which are accessed at run-time through a component integration architectura A component integration 
architecture Is a set of architecture mechanisms whfch allow software modules in <fifferent process spaces to utilize 
each others' capabilities or functions. This is generally done by assuring a common corrponent object mod^ on whwh 

to build the architecture. 

It is worthwhne to differentiate between an objed and a class of objects at this pd 

40 Of the class of Objects, Which is Often just called a dass. A dass Of objecte 
many objects can be formed. 

OOP anows the programmer to create an object that is a part of another object. For example, ttie ctiecX represent- 
ing a piston engine is said to have a confx>sition-reiationsh"ip with the objed representing a pistoa In reaTity. a piston 
engine conprises a piston, valves and many ottierconponents; ttie fact that a piston is an element of a piston engine 

4S can be togically and semantically represented in OOP tiy two otqeds. 

OOP also allows creation of an object that idepends from" another objed. If there are two ok)jects, one representrig 
a piston engine and the other representing a piston engine wherein the piston is made of ceramic, tiien the relationship 
between the two objecte is not that of composition. A ceramic piston engine does not make up a piston engine. Rather 
rt IS rnerdy one kind of piston engine that has one nxxelintetion than the pisto engjne; its piston is made of ceramic. 

50 In this case, the objed representing the cwamw piston engine is called a derived object, and it inherits all of the aspecis 
off the object representing the piston engine and adds further limitation or deteil to it The ok^ect representing the 
ceramfc pi^ engine "depends from" the oi^ect representing the piston engine. TTie relationship between these 
objects is called inheritance. 

VVhen the object or dass representing tiie ceramic piston engine inherits all of t^ 

55 ing the piston engine, it inherits the thermal charaderistics of a standard p'ston defined in the piston engine dass. How- 
ever, the ceranic f«ston engine ot^ect overrides these ceramic spedfic thennal charaderistics, which are typkally 
diffferBrt fron those assodaled witii a metal piston. It skips over ft^ 

pistons. Differart lands of piston wigines have different characteristics, but may have the same undertying functions 
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associated wHh it (e.g., how many pfetons in the engine, ignition sequences, lUnication. etc.). To access each of these 
functions in any pston engine object a programmer wouW call th^ 

of piston engine may have cfifferent/cvemcfing implementations of functions behind the same rama This ab'lity to hide 
(efferent in^lementations of a function behind the same name is called polymorphism and it greatly simplifies commu- 
nication axnonq objects. 

With the concepts of composition-relationsh?), encapsulation, inheritance and polymorphism, an object can repre- 
sent just about anything in the real worid. In fact our logcal perception of the reality is the only Rmit on determining the 
kinds of things that can become objects in objectK)riented software Some typical categories are as follows: 

Objects can represent physical objects, such as automobiles, in a traffic-flow sinrttjlation, electrical components in a 

circuit-design program, countries in an economics model, or aircraft in an air-traffic-control system. 

Objects can represent elements of the computer-user environment such as windows, menus or graphics ol^ecls. 

An object can represent an inventory, such as a personnel fiie or a table of the latitudes and longitudes of cities. 

An object can represent user-defined data types such as time, ang^les, and complex numb^ or points on the 

plana 

With thfe enormous capabifity df an object to represent just about any logically separable matters. OOP allows the 
software developer to design and implement a computer program that is a model of some aspects of reality, wh^er 
that reality is a physical entity, a process, a system, or a compos ition of matter. Since the ol>iect can represent anything, 
the software developer can aeate an object which can be used as a component in a larger software project in the 
future. ' — 

If 90% of a new OOP software program consisls off proven, existing components made from prerosbng reusable 
objects, then only the remaining 1 0% of the new software project has to be writtai and tested from scratch. Since 90% 
already came from an inventory of extensively tested reusable objects, the potential domain from which an error could 
originate is 10% of the program Ajs a result OOP enables softwere developers to build objects out of other, previously 
built objects. ». — - ^ » 

This process dosely resenttes complex macttnery being built out of assemblies and subassemblies OOP tech- 
nology, ther^a makes software engineering mae like hardware engineering in that software is built from existing 
corTfX)nents,wNch are available to the develoner as objects. All Vhis adds up to an improved quality of the software as 
well as an increased speed of its development. 

Programming languages are beginning to fully support the OOP princ^es. such as encapsulatioa inheritance, pol- 
ymorphism, and conposition-relalionship. With Hie olvent of the C4h- languaga many comm^dai software dev^opers 
have embraced OOP C4-h is an OOP language that offers a fast machine-executable coda Furthenmora C++ is suit- 
able for both commerdal-application and systems-programming kwojects. For now, G++ ^jpears to be the most popidar 
choice among many OOP progranmi«s, but there is a host of other OOP languages, such as SmaWtalK comnxxi lisp 
object system (CLOS), and Bflel. Additionally, OOP capabilities are bang added to more tratfitional popiiar computer 
programming languages such as Pascal. 

The benefits of object classes can be summarized, ^ loitaws: 

Objects and their corresponding dasses break down complex programming problems into many smaller, singer 
problems. 

EncapsuMion enfcxces data abstraction through the organization of data into small, independent objects that can 
communicale with each other. Encapsulation protects the data in an object from accidental damaga but alkjws 
other objecb to irteracl with that data by calling the objects menr*^ 
SubdEass/ry and inheritance make it posal)le to eodend and modify 0^ 

from the standard dasses available in the system. Thus, new capabilities are created without having to start from 
scratch. 

Polymorphism and multiple inheritance make it possWe for different programmers to mix and match characteristics 
of many different dasses and aeate specialized objects that can sb1l woric with related objects in predictable ways. 
Class hierarchies and containment hierarcNes provide a flexWe mechanism for modeling real-worid objects and 

the relationships among them. 

L&/arite of reusable dasses are useful in many situatk)na but they also have so^ 

Compiexity, In a conplex system, the dass hierarchies for related dasses can become extremely confusing, with 
many dozens a even hundreds of dasseSw 

Flow of control. A program written with the aid of dass fibraries is still responstole for theftow of control (i.e.. it must 
control the interactions among all the objects created from a particular library). The programmer has to decide 
which functions to call at what limes for which kinds of ejects. 

DupFica^nof^rt. Although dass libraries allow programmers to use and reuse many smafl pieces of coda each 
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progranwner puis those pieces together in a different way. Tv/o different programmers can use the same set of dass 
libraries to write two prognms that do exactly the same thing but whose interna! structure G.e. design) may be 
quite different, depending on hundreds of small decisions each programmer makes along the way. InewtaWy. sim- 
flar pieces of code end up doing sinr«lar things in slightly different ways and do not wortt as wefl together as they 
should. 

Class Itoraries are very f lexWe. As programs grow more complex, more programmers are forced to reinvent basic 
solutions to basic problems over and over again. A relatively new extension of the dass library concept is to have a 
framework of dass Iftxaries. This framework is more complex and consists of significant collections of collaborating 
classes that capture both the small scale patterns and major mechanisms that implement the comnxxi requirements 
and design in a specific application domain. They were first devetoped to free application programmers from the chores 
involved in displsying menus, v«ndows. diatog boxes, and other standard user interface elements for personal comput- 
ers. 

Framewort© also represent a change in the way programmers think about the interaction between the code th^ 
write and code written by others. In the earty days of procedural programming, the programmer called Itoraries provided 
by the operating system to perfomi certan tasks, but basically the program exe^ 

and the programmer was sol^y i esponsiWe for the f tow of control. This was appropriate for printing out paychecks, cal- 
culating a mathematical table, cs solving other problems with a program that executed in just one way. 

The devetopment of graphfeal user interfaces began to turn this procedural progranrvning anangenwit inside out 
These interfaces altow the user, rather than program togfe, to drive the program and dedde when certain actkxis shouW 
be perfonned. Todc^ rPcHTpe.'sonal computer software accomplishes this by means of an event kxjp which monitors 
the moi^ keyboard, and other sources of external events and calls the appropriate parts of the programmer^ code 
according to actions that the user performs. The programmer no longer detenrones the order in which events occur. 
Instead, a program is divided into separate pieces that are called at unprecfictable times and in an unpredictable order. 
By relinquic^ng control in this way to users, the devetoper creates a program that is nrwch easier to use. Nevertheless, 
individual pieces of the program written by the devetoper still call libraries provided by the operating system to accom- 
plish certain tasks, and the programmer must still detennine the fkw of control wnthin each piece after its called by the 
event loop. Applk^atkxi code still isits on top oT the system. 

Even e/snt kxjp programs require prog^mnriers to write a krt of code th^ 
for every ^ication. The concept of an appfication frameworit carries the event loop concept further. Instead of dealing 
with all the nuts and bolts of constructing basic menus, windows, and diatog boxes and then making these things all 
work together, programmers using appltoation frameworics start with wortdng appltoatton code and bask: user interface 
elements in placa Siibsequently, they buiW from there by repfadng some of the generic capaWlities of the framewort^ 
with the specific capabilities ef the intended appltoation. 

Application framewori® reduce the total amount of code that a prograiraner has to write from scratch. Hcwever, 
because the frameworti IS reaUy a generic application tfal displays wire the 
programmer can ateo relinquish control to a greater degree than event toop progBins permiL The frameworii code 
takes care of almost all event handling and ftowolcontrd, and the progranm^ only when the frame- 

viKHk needs it (e.g., to aeate or manipulate a propri etary data structure) . 

A pro^ammer writing a franrwwori^ program not only refinqufeh^ 
programs), but also refinquishes the detaaed ftow of control within the program to the frameworit This approach altows 
the aeation of more complex systems that woric together in interesting ways, as opposed to isolaled programs, having 
custom code, being created over and over again for simlar proWerTK. 

Thus, as is explained dt>ove, a frameworkbaskadly is a cdledfonol cooperating classes th^ 
design solutton for a given problem domain. It typtoally indudes objects that provkle default behavfor {e.g., for nrienus 
and windows), and pro^ammers use ft by inheriting some of that defautt behavtor an^ 
the frameworic calls appltoatton code at the appropriate times. 

There are three main dfferences between framewaks and dass libraries: 

Behavior versus protocol Class libraries are essentially collections of behavtors that you can call when you want 
those indivtoual behavtors in your progran^ A frameworit, on the otiier han^ 

protocd or s^ of rules that govern the ways in which behavtors can be conrttned, induding rules for what a pro- 
granvner is supposed to provtoe versus wfiat the framework provides. 

Call versus override. With a dass Bbrary. the code the programmer instantiates objects and calls their member 
functions. IfB possible to instantiate and call objects in the same way with a framewortcOe., to treat the framewortc 
as a dass axary), but to take full advantage of a frameworicte reusable design, a progranOT 
that ovenides and is called by the frameworie The frameworit nrianages the ftow of contrdarnong its object 
ing a program invohres divicfing respor^l)iIities anrw^ 
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work rather than specifying how the (fiffer^ 

tmp^mentation versus design, Vm dass libraries, programmers reuse only implementations, whereas with frame- 

worte. They reuse design. A frainework embodies the way a farrt 

It reprUents a generic design solution that can be adapted to a variety of spe^ 

example, a single framework can enrtxxJy the way a user interface works, even though two different user interfaces 
aeated with the same framework might solve quite different interface problems. 

Thug, through the devetopment of frameworks for solutions to various proWenre and programnrring tasks, signif kant 
reductkxis in the design and development effort for software can be achieved A pr^erred embodiment of the invention 
utifizes HyperText l^tokup Language (hfTli/ig to implement documents on the Intemet together vwth a general-purpose 
secure communication fwotocd for a transport medium between the client and the merchant HTTP or other protocols 
couW be readily substituted for HTML without undue experimentatioa Infonmalion on these products is available in T. 
Berners-Lee. D. Connoly, "RFC 1866: Hypertext Markup Language - 2.0- (Nov. 1995): and R. Relding. H, Frystyk. T. 
Berners-Lee. J. Gettys and J.C. Mogul, "Hypertext Transfer Protocol -4frTP/1 .1 : HTTP Wbrtdng Group Internet Draft" 
(May 2. 1996). HTML is a sirrple data fomrial used to create hypertext documents that are po 
to another. HTML documents are SGML documents with generic senfantics that are appropriate for representing jpfor • 
matfon from a wide range of domains. HTM L has been in use t>y the WbrW-Wide Web global information initiatr^e ^pce 
1990. HTML is an applfcation of ISO Standard 8879:1986 Infornration Processing Text and Office Systenrs; Standaid 
Generalized Marfoip Language (SGML). 

To date. Web development tools have been limited in their ability to aeate dynamic Web applications which span 
from dient to server and interoperate with existing computing resources. Until recently.^bTML fes the dontinant 
technology used in development of Web4)ased solutfons. However, HTML has proven to be inadequate in the following 
areas: 

o Poor performance; 
0 Restricted user interface capabilities; 
o Can only produce static Web pages; 
o Lack of interoperatMlity with existing applications and data; and 
o InatMlity to scale. 

Sun Microsystem's Java language solves many of the dient-side problems by: 

o Improving perfbmiance on the dient side; 

o Enabling the creation of dynantic. real-time Web appUcatfons; and 

o Providing the ability to create a wide variety o« user irterfaceconponente 

Java is corrpiled into bytecodes in an intermediale form instead of machine code (like C, C++, Fbrtraa ete.). The 
bytecodes execute on any machine with a bytecode interpreter. Thus, Java applets can nin on a variety of dient 
machines, and the bytecodes are conpacl and designed to transmit e!f tdently over a networtc virhich enhances a pre- 
ferred embocfiment with universal clients and server-centric polides. 

With Java, devetopers can create robust User Interface (UQ components. Custom \wdgets" {e.g. real-time slock 
tickers, animated icons, eta) can be created, and dient-side performance is improved. Unlike HTML, Java supports the 
notion of dient-skJe validation, offloadng appropriate processing onto the dient for improved performance. Dyrmmic, 
real-time Web pages can be created. Using the above-mentioned custom Ul components, dynamic Web pages can 
also be aeated. 

Sun's Java language has emerged as an industry-recognized language for "programming the Intemet." Sun 
defines Java as: "a sinple, object-oriented, distributed, interpreted, robust, secure, architecture-neutral, portable, high- 
perfonnance. multithreaded, dynamic, buzzword-compliam. general^xirpose programming language. Java shorts 
programming for the Internet in the fomn of ptatfoonnndependent Java applets." Java applets are small, speaaTized 
appfications that corrply with Sun^fe Java Appfication Progranwrtng Interface (API) allowing devetopers to add "intwac- 
tive contenr to Wdb documents (eg. simple animations, page adornments, basic games, ete.). Appl^ execute vwthin 
a Java-conpatWe browser (ag. N^scape NavigaloO by copying code from 

point Java's core feature set is based on 0¥+. Sun's Java literature states that Java is basfcally "Cf+. with extensions 
from Objective C for more dynamic method resdutton". 

Another technology that provWes similar fundfon to JAVA is provkJed by Microsoft and ActiveX Technologies, to 
give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. 
ActiveX indudes tods for devetoping animatk)n, 3-0 virtual reality, vkleo and other multimedia content T^^ 
Intemet standards, work on multple platfomris, and are being supported by over 1 00 companies. The groip's building 
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blocks are called AdweX Controls, smaD. fast co^ 

tod markip language (HTML) pages. ActiveX Controls work wnth a variety of pro^amniing languages including Micro- 
soft Visual C++. Borland Delphi. Microsoft Visual Basic programming system and. in the future, Microsoft^ 
development tool for Java, code named "Jakarta.* A«*veX Techndo^es also includes ActiveX Server Ramawxk, 
aUowing developers to aeate sewer appficatkxis. One of ordinary skiQ in the art readty recognizes that ActiveX could 
be substituted for JAVA without undue ©tperimentation to practice the invention. 

A prrferred entoodiment provides a system for buikJing manageable applications. The applications can be readily 
deptoyed. on to a variety of platforms, and configured so that if s easy to part^ 

adntnister the applications. A preferred embodiment is enabled ^ a cfient server applrcation thaTs distributed nodes in 
a mufti-node platfonn. A single applwation is (Svkled up into pieces and distributed aaoss nodes in the network. Thus, 
an appHcatfon is defined as a distributed system 

Enterprise conputing systems often a heterogeneous collection of nodes interconnected by a network. In a typk:al 
environment a server node in the networic hokte data and progranre ttet irteract with the datab^ node 
contains a program or programs for accessing the information on the server. The complexity of these environnients 
mates ft difficuft to aeate, configure, deptoy and adntinister software applwations. Howe^^er, the advent of Web technol- 
ogies (browsers, the Java language and HTTP) has enabled enterprises to create and use internal Wdjs to assist in 
solving some of these problems. Java enables the Web as a client-server apf^iration platfomi and distribution channel 
to interact with a prefen^ed entxxSment in addressing many of the aforementioned challenges. 

A preferred entxxJiment includes a toolkrt for creating client programs fliat can be downtoaded from the Web; inter- 
faces for enabling a server program to function with a client as a single applfeation; tools for connecting both dient pro- ^ 
grams and server programs wrth a framewortc for executing toe toolS; and tools for instafling. deploying and 

administering applications. 

An applk;ation created in accordance wito a preferred entxxlimert consists 
wnto each otoer. A server conponent can be implemented in any source language that can call a C program A client 
conponent is inplemented in the Java programming larigi®ga-The dientjSLnrponent consists of a GUI and a Presen- 
tation Engine (PE). To conplete toe appTication system, a-prcferred iimbqdiment provides a conumrication layer that 
enables toe exchange off messages between toe client and toe server components, an Exception l^er for reporting 
errors, and an Access layer for managing application deptoymenL The task of an apprication developer utilizing a pre- 
ferred enrrtxxliment is to assemble toe components into an application systera 

A preferred entxxJiment provWes Java client access to.s^rver an^ications and can be utilized to aeate new appli- 
cations or extend existing applfcations. Among exfeting applrcations, those tr^ are partitioned so that server programs 
and databases are on toe server, and user irterfaces are on toe cfient are especially surted f^ 
entxxJiment Other applications especially surted to a preferred embocfiment require access to departmental or corpo- 
rate data wfthout changes to databases or toe programs that access toem. For enterprises alre^ 
nofogies in an Internet Intranet or otoer network environment, appEications in accordance wito a pr^erred embodiment 
provkJe qakM access to existing data from anywhere in toe organization or toe worid. Applications in accordance wito 
a prefened entxxfiment can execute on any processor wito toe Java interpreterMmtime (Java JDIQ or JavaOS 
installed. Applk»tion client programs are developed in Java using a null appfication template that contains the neces- 
sary Java classes and m^hods for integration vwto a Graphical User Interface (GUI). The template includes Java 
classes whfoh will alfow toe dient program to comnwrtcate wito toe senrer program. Scripts and tocrfs for installing and 
deptoying appfications, include a generalized startup applet for applfeation launch from a Web browser or applet viewer. 

The primary devetopment task in accordance wfth a preferred embodiment is to create an applfeation front end 
referred to as a Presentation Engine, hereinafter (PE). from a provided template. The PE template includes m^hods 
(togfo in an object) to send messages and toeir date through a client communfoation library. Developers mocfify toe tem- 
plate to specify toe messages and data reqiired for toeir application. The comnwnication library handles toe passing 
of messages and date across toe network The PE toolkrt supports toese tasks. The toolkrt is a full se* of Java compo- 
nents whk*i can be modified and extended for a partkailar appfic^ 

be enabled to communicate wrth toe client by specifying which handler functfons are called in response to inbound mes- 
sages and inserting "Isend" calls to a server-toe^ comnwnication library when data are sent to a dient The two PE 
development tasks are to: (1) connect a Java Ul to toe PE frameworit, and (2) defineWescrtoe toe messages to be 
exchanged between toe PE and toe senrer. 

AU of the conponents in accordance wrth a prefen-ed embocfiment reskle on the server so ^ 

an access to rts resources. The server thus controls deptoyinem and adrrtn^ 

use toe web to access the server^ resources. A template IS also provided for creating an a^ 

client nodes to start applications from a browser whkrfiwfll be dscussed in added deta^ 

Figure 4 is a block diagram in accordance wrth a preferred embodinf^ariL The cfient 410 and back end server 400 
create and receive data messages comnuntoated via messages at toeir focal communfcation Gbraries 420. Messages 
are events wttch are encoded in a prolDcd, W layered on top of TCP/IP Tte 
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be inr^emerted on any network protocd as asy^ passing on top of a communication 

protocd, such as TCP/IP. avoidng the cSependendes 0* any parties 
d message events, and each conponent (front 410 and back 4CK) ends) 

events. Thus, any two components can be plugged into the execution framework 430 to form an applkation 440 if they 

5 include local handlers for messages in the set of message events drfined for the application 440. The components each 
include a kxxil instance of a communication library 420. A component only interacts with the Application Programming 
Interface (API) of its k)cal communication Ibrary 420 in order to send or receive message events. 

Application components in accordance with a preferred entxxJiment are loosely coupled" because there is no 
direct dependence (or communication) between the components. The execution framework 430 provides a consistent 

10 connection for all message transfer for the various applications. The execution framework 430 supplies additional serv- 
ices, such as error reporting, for the oonnedfon. An application 440 is insulated from the physics properties of the spe- 
dfic distributed platform on which the application is deptoyed. Thus, the application components and set of message 
events remain constant while the distrftxjted platfonn can be scaled and modified. 

Since applications 440 are systems containing well defined components as is shown in Figures 4 and 5, it is pos- 

75 sWe to install sets of front ends 530 and back ends 540 plus the definitions dhow to 

440. The server, therefore, hokte all the resources while the dient 500 can only request access to the resources. The 
server 520 is extended to altow it to control access to its resources by enforcing wdl defined policies. 

Figure 5 illustrates how a prefenred embodiment leverages Java to facilitate the establishment and implementation 
of server-centric policies. The oient and senrer nodes communicate utilizing the web technologies in an Internet 

20 Intranet or other network environment The client node 500 contacts the server node 520 via HTTP with a request to 
execute an applicaticm. After "authenticating the client 500, the sender node 520 selects front 502 and back end 510 
conponents based on the application definition list maintained at the server node 520. The server starts its back end 
process 510 and sends the front end program 502 to the dient node via the Web technologies in an Internet, Intranet 
or other network environment The dient 500 executes the selected front end 502 tocally at the dient node 500. The 

25 front end (dienQ-programs operLa TCP/IP connection back to the server to initiate nrressage passing in order to run the 
appTicatiOiTS. Thefront end program 502 is implemented entirely in Java which fadlitates instances of dient^server appli- 
cations which can run conairrentiy on a set dnruiltii)latfdrmdients. The server 520 is able to send a front end program 
502 to any dient node 500 which has the Java runtime installed on the computer. Sender polides will not involve tiie 
diertts. The policies will focus on tiie server^ control of its focal resources. 

30 Figure 5 also illustrates 4he loose coupling l)etween the front end 502 and the back end 510 appTication conrpo- 
nents. Each pro-am indudes a focal ccnrmiunication lil)rary 51 5. The front end library is implenr>ented in Java, the back 
end library is inplemented in Gh- with a C API. The programs each utilize their local communication library API to send 
and receive ntessages. Thus, t\e programs do not oomnrunicate directty with each other. 

35 Presentation Engine 

There are two phases for each application executioa In the first phase, appfication startup, the dient node requests 
access to the server node's resources and the s&ver acts on this request The nodes are associated via the Internet 
or other conwminication nelworic, and thus do not have a permanent relationship vnthin the enterprise. In the second 
40 phase, appfication ocecution, the dient has received a front end Java program called a Presentation Engine (PE) to 
fodGtate presentation services. The front end and back end.are commumcating via tiie execution frameworic over 
TCP/IR 

Figure 6 illustrates the processing assodated with application startup in accordance witti a preferred embodiment 
When an appfication is started, the dient node executes a startup applet 620 which first coileds infonnation about the 

45 dient 600 user and contacts the server node 610 via http 602. The server node 610 has been extended to indude a 
web server 630 for processing requests via KTTP over the Web technologies in an Internet Intranet or other networic 
envirorwient The access layer 640 is called via a cgi-bin interface from the web sender 630. The access layer 640 pro- 
vkles a framework so that the information about the dient user, for example userid and password, can be used to call 
server-reskJent authentication sennces. Should autiientication be successful, the access layer 640 uses the application 

so name, which is also supplied by the startup applet and invokes the app manager 650. The app manager 650 handles 
the application definitions inslafled on the server node 61 0. The app manager 650 selects the appfication back end 660 
and iritiates ttie processing. A Bstener socket is opened on the sender node, and the port n^ 
manager 650. The ap manager 650 also selects the appfication Front End (FE) 670, stored on the senwas a set of 
Java bytecodes, and aeates a PE 670 instance which indudes the Rslener socket port number. Appfication startup 

55 ends when the PE 670 instance is downtoaded to the dient node for execution. 
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Application Execution 

When application execution is Initiated, the client node begins to interpret the PE 700 (Figure 7) it has received from 
the server node 710. The PE 700 is a framework (which includes an User Interface (UO which can indude a graphical 
Ul (QUO) and an instance of a communication library 720 implen^ the PE 700 opens a 

socket connection to the server node 71 0 utilizing ttie server port nunto it was suppli^ 
650 started the back end process 730. The back end process 730 on the server node 710 ma^ 
which encapsulates an interface to a Data Base Management System (DBMS) 712. The front end 700 focuses solely 
on presentation servrces and its own web access capabilities. The execution framework 724 spedftcally links the front 
end conponent 700 to the back end conponent 730 using event^riven message passing 735. This design preserves 
modularity between the from end 700 and the back end 730 of an applica^ 

During application e)©cution. the sender node 710 communication library 720 manages the connection to fadlitate 
policies that maximize access to Hs resources. For example, a server can be configured for a maximum time to awaita 
transaction response. A timer runs, if it exceeds the maximum time before new dient messages are received the server 
will terninate the dient connection and recyde the port The execution framework 724 supplies runtime error reporting 
servk^es and application execution data which are accessible to system administrators via Web techndofipes in an Inter- 
net, Intranet or other network environment access. When application execution terminates, the relationship between the 
dierit node 700 and the server node 71 0 also tenninates. Application startup must occur each time application execu- 
tion is desired. 

A dient^ presentation engine can be stored on the dient node and Parted dynantically if tiie presentation engine 
"is cached on the dient. The reason for storing the presentation engine in cache is to support mobilejnpmadfc) comput--^ 
ing, perfonnance and to reduce network traffic. This technique would require versioning to assure mat the presentation 
engine is synched with the latest, most current release on the server. 



-/^plication Devetopment . 

The application devetopment process in accordance with a preferred embodim«it is a system integration task 
rather than a third generation language programrrtng task. Figure 7 illustrates the three fundamental components of an 
appfication in accordance with a prelenred embodiment The front end. dient skle 700. the back end 730 server skle 
710, and the execution frameworit 724 which facilitates the connection between the front end and the ijacJx eiid. "me 
appTiostion developmwit process consists of a plurality of steps. The first step defines the responsibilities of the front 
and back end conponents. A fweferred embodiment is designed to fadlitate rrtgration of existing dientfeerver applk»- 
tions to function utilizing the Web technologies in an Irrternel, Intranet or other network environment for conminicalk>n 
sanrices. This n^gration does not reqiare redesigning existing appfication logic. The process entails the implementation 
of a new PE front end inplemented in the Java language which exchanges message events with the remaining server 
back end coda Figure 8 niuslrates the nngration of an easting dient-server appfication to one supported by a preferred 
embodiment 

The new Java PE front end 820 is added to the existing application code and will contain the Presentation Layer 
(Ul tier) 800 and some amount of non^database aware togic responsible fry manipulating variables. All togic which is 
aware of ttio database and its data remains in the back end component The PE 820 is nrt 
ing application. It is a program inplemerted in Java, and thus can tal« dired advantage of adcfi^^ 
sen^ices within the enterprise intranet The complexity of the PE is detenmined by the devekper^ chok:& 

The second step in mgrating existing applications to utilize a preferred embodiment is to defne the message 
events exchanged between the PE and the back end. The PE and the back end are loosely co^ 
eventSw Each evert has a uik^ue name and data assodaled with ttie event l^essage w 
type, an primitives plus one conposite type. Message data types directiy map to prinv^ 
communication Iftxaries have APIs whkii can be used by developers to define message events. 

The third step is to set ip the bade end to handle rnessage events. The server residert ba^ 
handle message events. This procesdng is enabled by linking in an instance of ^ 

sewer coda The communication Hxary has a C API, so the server code can be inplemented In any language which 
can call C. The existing server code utilizes the conimunication 1^ 

nkationltorary calls handler ftjnctions in the server code when message everite Thedevel- 

oper will create these handler functions and register them, one handler function per defined mesjsage evert, using APIs 

in the communication library. j 
Once conpned and finted, the back end is a single process which is started by the app n^ 

irtttiation. The hiterface between the server conmwiicatkw 

The foirti step is to develop a Presentation Engine front end. Java is utilized for this task. Templates and tools are 
provided to fedlitate this task. The detailed taste associated with fedr^ 
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The final step in nigraling an existing cfient server applicalion to a preferred enrtxx&nent is to install application 
conponenls on the server node. Both the front end (dieng and l)ack-^ 

A Java startup applet ^)al>!es cHents to access the appTKation on the server. A set d tools fc^ installation 
and conTiguration are provided as applications on server nodes in accordance with a prefen^ed embodiment A Java 
startip applet terrplate is also provided to fadlitate development of the application^ startup applet 

Presentation Engine Development 

Pres«Ttation engine development is the step of developing a new application front-end in Java, To simpfrfy this task 
and provide application performance and rotxistness guarantees, all application front ends are instances of a single 
dass of programs. A basic presentation engine frameworit implemented in Java is provided as an example in accord- 
ance with a preferred entxxliment Developing a specific application presentation engine means extending and cus- 
tomizing the basic presentation engine framework template. A Presentation Engine (RE) is itself a system with two 
conponents: (1) a Ul inplemented in Java, and (2) the RE framework. Developing a RE is a system integration task vnth 
the following two steps. 

(1) Develop a Ul which Is innpiemented wHh Java. 

Figure 9 is a btock diagram illustrating a RE 960 in accordance vwth a fweferred embodiment The Ul 900 compo- 
nent is developed according to a devetop^s particular requirements. Since the front end processing utilizes the Java 
language, the Ul also takes advantage of Java's rich functionality. The Ul 900 is connected to the RE 960 frameworit via 
an interface to the Ul Adaptor 910 conponent. The interface is a general message-passing interface that fadTrtales the 
attachment of any Java inplemented Ul 900 with the RE 960 framework to exchange data events. An API is provkled 
to the RE 960 framework so that a devetoper can link the Ul 900 to the Ul Adaptor 91 0. 

(2) Extend the PE Framework Template (960) — — - 

Figure 9 fliustrates how the RE Ramework 960 architecture is arranged to fadTrtate two kinds of external events in 
accordance with a prefOTed embodiment The two kinds of external events a^^ 

Execution Framework. The framework indudes a Java implemented cocranunication lixary component, the Comm 
Adaptor 950. The RE framework 960 interlaces to the Ul 900 via the U I Adaptor 91 0 and interfaces to the server TCP/IP 
connectfon via the Comm Adaptor 950. The mecSator 920 component handles ail external events moving into and out 
of the RE framework 960. 

The Ul 900. Ul Adaptor 910 and the Model 940 are directly extended by the developer supplying applicatfon spe- 
cify infbnnatton. The commurncation library and mediator components are not extended ty devetopers. The PE frame- 
work 960 has a model 940 -view 930 -contndler architectura A dev^oper may extend the Modd 940 componwrt m 
order to inplement kxal togc and maintain RE-tocd slate. The view conponent 930 maps between the Mode! 940 date 
representatkxi and the messs^e data representatfons. 

It IS possible to aeale a RE franriework without extending the Model 940 con^ 
model is refwed to as a TEW option and consists of the conrnacfaplor 95^^ mediator 920. Ul Adaptor 910 and the 
Ul 900. To utilize this optioa a devekperassenibles the conponentsfi^ 
The RE framework 960 makes use of the Medator 920 to directly map between Ul externals 

events. 

The execution framework 960 is a communication abstractfon that utilize TCP/IP as a communteatiori backbone, 
and is anatogous to a bus in a computer system. Each coriponert in accordance with a preferred enrtxxJirnent plugs 
into the execution framework rnuch as vark)us functfon cards plug into the bus of 
of tocal versus remote in the components which is unlike a typfeal distributed corrputing environn^ent 

In thfe architecture, there is no distributed domaia Everything is tocal and the way that a component connects ip 
with this frameworii is by making local calls to a communication fayer which is the framework. ITs all enixxfied in the 
communicatfon library conponents. Sa the messages that are exchanged between programs are data. Rather than 
functfon calls, they are actually data cwitainers. All that can happen in the exchange is that data are packed up and sent 
as an event or data are packed ip here and sent over there as an event 

InskJeofthedientandsenwprogreuns. there are handlers for the detain the nriessage events. So, any front end 
and any back end has tocal handlers for a comnw set of message events. Th^ can be ^ 

woric to CTeate an applicatkw. Sa what we call these is. Toosely coupled", which means that there are no dependendes 
between the programs and they do not communfcate directly. This preserves modularity in the appTicatiai A program 
m^ send data events, and the program also is enabled to handle data events wh"i^ 
The framework curreitly is fayered over TCP/IP for a communk»lk)n 
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utilized The programs always interact with the ICE-T Comm Layer. There is a firewafl between the actual, physical <fis- 
trftxrted platfonn. undemeatti and the application dtxDve becai^ the apfrficalion components are interfacing with the 
abstraction. Thus, applications are independent from the d^Ts of the physical structure of the distrftxited enterprise. 
The ent^pr^ may be scaled, and/or modified without requiring redesign of the applications. 

Example In Accordance With A Prefen^ Embodiment 

Rgure 10 is a block diagram of a prior art client server architecture. In the prior art a dient computer 1000 would 
access a network 1030 via a predefined data protocol (datastream) and interact with a pred^ned serv©^ 1001 contain- 
ing code 1010 and data in the form of a DataBase Mar^gement System (DBMS) 1020. 

An application in accordance with an alternate embodiment is shewn in Figure 11 . The encapsulated DBMS 1102 
is conserved, as is the enormous investment in code 1170. However, the server 1180 includes a service AP1 1160 for 
communicating to the networic support 1 1 50 which is responsWe for turning the web node into a k)osely coupled client 
1 120 utilizing a small amount of Java code and conforming to a predefined datastream that is sent l>y the serve- 1180 
to the dient 1 1 20. A web server 1 1 06 is utilized to fadlitate access to and transnrassk>n of messages over the web from 
the server 1180 via the access module 1108 and the PE franriework 1104 as discuss^ 

Figure 12 illustrates a server 1210 estabfishing contact with a cCent 1200 in accordance with an altemate embodi- 
ment The code 1240 and DBMS 1230 are as descrft>ed in Figures 10 and 11. However, web contact is established 
between the nodes by authenticating a user iftTizing the Access Layer 1280 to 

munication. Then, the Java bytecodes 1250 are extracted from the PE Repository 1290 and downloaded to the dient 
1200 using the Access Layer 1280 and the Server 1270. 

Figure 13 illustrates a kxjsely coupled dient - sender application in accordance with an alternate embodiment The 
Server 1300 comnwnicates via a service AP1 1 360 and Networi^ Support 1340 to a aient 1330 utilizing a predefined 
data stream 1350 and application code 1320 ^nd a DBMS 1310. The noosely" co^ 

tecture is enabled through message conmioicatkMi in an asynchronous manner letting the Client 1 330 and the Server 
1300 mantain state independence and connect via a tow bandwidth networi« 1350. The appfications require no function 
can level API^ 

Some of the basic architectural design decisions that iam the foundation of a preferred embodiment indude the 
Server 1300 contrdlir.'g both the Client 1330 and Server 1300 states. The Java language is utilized to communlc^e via 
the Web technologies in an Internet Intranet or other network environment to cfistrfbute Qient 1 330 state infomiation to 
the aient node. The Server 1300 presents an encapsulated DBMS interface to the network. The Server 1300 node is 
e)dended ty a frameworic to support the establishment of a Cfient 1 330 -Server 1300 relationship for web nodes. 

The Client 1330 - Server 1300 relationship for web nodes is established utilizing a secure htlp process which 
authenticates the user a: the requesting node. Then, the Qient 1330 node is established by selecting an appropriate 
aient 1330 slate from stored states at the Server, and the Java dient s^ networi^tothepar- 
tkxilar Client 1330 node Next the aient 1330 -Senw 1300 networttconrmirticationsessfon is conm 
the server process and esfabfishing a socket connection to the Ctient 1 330 noda Once the sesskxi is established, then 
the network must be managed by maintaining event-driven message passing with the PE commuiication library. 

Figure 14 Olustrates the system intonation task necessary to devetop an appTK:^^ 
fened embodiment First the developer defffies the message events 1450 that must be exchanged between conpo- 
nents. The cfiert program 1410 and server program 1420 are d^ined as applk»tion^ 1430 on the Server tkxJe 1420. 
The back end must be enabled to send and receive messages. The front end (PE) must be devetoped, then the com- 
ponents are installed in the server node 1420. The goal is to support modular application devek)pment and require min- 
imal additional knowledge burden (e.g. sophi^k;ation in Java or OOP) from devetopers. 

Figure 15 is a block diagram illustrating the modular design of a dient appIk»tion (PE) in accordance with a pre- 
fened embodiment The application logic 1530 is written entirely in Java to maximize access to Intemet fadlities. The 
appOcation logfc mns as a Java program or an applet An Bctemal Irtterface Li3^ 

Irons for interfadng to the Ul or AP1 1500 through the Ul layer 1510. A Message Ubrary 1540 provides messages for 
use in communicating information through the communication layer 1 550 to the Sender 1 560. The arch'itecture is a dient 
loosely coupled with the server 1560. Data exchange is via event^lriven message passing. AflexUe Ul 1510 and com- 
murocation layer 1550 facflitates message passing APIs interfadng to a Server or Ul designs. Developers are not 
required to understand networtc communication or system programming in order to design and implenr>ent applications. 
The dient program can be designed to si<5port effkaent presentation sendees. The DBMS intertace is encapsulated in 
the back end (server). Thus, there are no dislrftxited transactions whteh must be handled in the web connection 
t>etween dient arxj server. 

Figure 16 is a bkxiidagram of a frameworii in accordance with an alte^ Model data 1600 is pro- 

vided in the form of pred^uied classes that can be accessed and nwdir^ 

meet the requirements of a particUarappTicalion and specify appropriate components. AH of the 
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dass tenplates necessary to be extended into a fully functional model are provided. The Model data 1 600 is utilized on 
the external IF View 1622 and aJdrtional model data 1620 may l)e added as necessary to expand the view. Simaarty, 
the message view 1612 can be expanded by adding additional nrxxlel data 1610 to the message view 1612. A mediator 
1630 is responsible for routing messages and granting control to the Communicatiwi Adaptor 1640 or the Ul Adaptor 
5 1650 

Figure 17 illustrates the basic building Wocte in accordance with an alternate embodiment A PE object 1700 is an 
ol)ject containing methods (lo^c) and data (public and private information) that is utilized to facilitate a reusable, exten- 
sible function. A PE function 1 71 0 utilizes PE objects 1700 to implement callbacks, observers, event handers and maps 
in accordance with a prefen^ed entxxfimenL PE Info 1720 is a basic unit of data moved b^een functional compo- 
10 nerits. and a PE Event Handler 1730 is used by views to handle incoming messages and 
a preferred embodintenl 

Figure 18 is a block diagram highlighting the steps utilized to extend the (PE) framework in accordance with a pre- 
ferred enixxJimenL A user must modify the Ul Adaptor 1800 as shown at 1810. All of the base processing necessary 
to facilitate the application is incorporated into the basic framewak which provides all of the basic classes fa instant- 
15 ating objects necessary to perform user^ requrennents. 

Figure 19 IS an fliustration of a PEObjed 1900 in accordance with a prefen-eder^ PE object is a data 

^ructue Itorary that is used for building the model and other structured data passed around in messages. There is an 
associated containment hierarchy witfi printitive 1910 and composite 1920 objects instantiated from the base PE CX^ect 
1£00. An objecKiriented architecture fadlitates polymorphic, encapsulated objects that are fully setf<jescribing and 
20 fully enabling for a serialization interface. 

^ ' Figure 20 is an illustration of a PE Event Handler 2000 used by Views to handle incoming messages^and Ujevents- 
in accordance with a prefmed embodiment. The PE Event hHandler 2000 di^ 

data d^ed in objects PEInfo 2010 data which is passed utilizing a message to implement a map to the nrwdel. Figure 
21 -llustrates a PEInfo object 2100 data in oxxMdance with a pr^err^ 
25 message signatures and is used in three places ft)r passing between model and XIF View, Model and M?S View and 
XIF View and the Ul. 

Figure 22 illustrates incoming message flow to a model in accordance with a preferred embodiment A message 
ftows into a communication layer in lytestream format 2200 and passed via a m^^ view 2210 to 

unpack and dispatch the message utilizing a MsgHandler PE Event Handler to transfer the PEInfo 2220 data. The 

jo PEInfo 2220 is used to encapsulate the event and message signatures and transform the message intg a rrnxi^ nfiap^ 
, 2230 which is thereafter utilized for setValue and gelValue processing 2240. When a Ul Event, such as a key press or 
other activity occurs at 2260, a callback PE Function 2270 utilizes PEInfo 2280 to pass event and data information to 
the external view dispatcher 2290 for transfomiation into information that the Model PEObjecl 2250 can utilize for fur- 
ther message processing. 

35 Figure 23 Hluslrales incoming messages mapping a Ul to a Model in accordance with a preferred embodiment in a 
manner very similar to Figure 22. Figure 24 illustrates outgoing messages mapfwig a model to messages in accord- 
ance with a preferred enfoodiment in a manner sinwlar to Figures 22 and Figure 23- Figure 25 illustrales outgoing mes- 
sages mapping a model to a Ul in accordance with a preferred embodiment in a manner similar to the foregoir^ 
Rgures. To further clarify processing in accordance with a preferred embodiment, the d^led installation and togic 

40 spedTKation for an application in accordance with a prefen-edeni^ 

Enterprise conputing environments usually consist of many kinds of nodes interconnected by a networit Inatyp- 
ical environment, a server node in the networtc holds data and programs that interact with the database, and a client 
node contains a program or programs for accessing the infomiation on the server. The complexity of these environ- 
ments nrakes it cfifficult to create, configure, deptoy. and adrtBnisler software applications. The advent of Web technol- 

45 ogies (browsers, the Java tenguage.KriP) has enabled e^ 
some of these problems. 

Java enables the Web as a client-server application piaUbrm and cfistribution channel. The "Interprise" Computing 
Environment Toolkit (ICE-T) enables building, extending and deptoying dient-senrer appTications for the Welx flnter- 
prise" combines the internet and the enterprise.) 
so The ICE-T application provides: 

• A toolkit for CTeatingdientprogranris that can be downloaded on the Web 

• Interfaces for enaWing a server program to wori^witii a client as a single application 

55 

• The tools to conned both dient program and server programs to a frameworit for executing them 

• Tods for installing, deptoying. and Eriministering applications 
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ICE-T Applications 

An application consists of a server program component (implenr^ented in any language ttiat can call C) and a dient 
program conponent Ctnplemented in Java). The client component consists of a GUI and a Presentation Engine (PE). 
To conplete the application system, ICE-T provides a Communication Layer that enables the exchange of messages 
between the client and server components, an Exception Layer for error reporting from ICE-T components, and an 
Access Layer for managing how appfications are deployed. The task of the ICE-T application developer is to assemble 
the components into an application system. 

ICE-T provides Java client access to server applications. New applications or existing ones extended utilizing a pre- 
fened embodiment Among existing applications, those that are partitioned so that server programs (business logic) 
and databases are on the server, and user interfaces are on the client (three-tier diwit-server applications) are espe- 
cially suited for migration to ICE-T front ends. 

ICE-T is especially suited for enterprise applications that require: 

• Access to departniert or con?crate data without changes to datdaases or the program 

For enterprises already using an enterprise vweb technolo^es in an Internet Intranet or other networit environ- 
ment ICE-T applications can provide quick access to existing data from anywhere in the organization or the fieW 
where there is an internet connection. 

• Client platform independence. 

ICE-T Presentation Engines can run anywhere the Java Virtxj^ Mainline is present _ 

Rapid devetopment 

Clients are developed in Java using a null application template that contains the necessary Java dasses and 
methodsfaimegrationwithaGUIandaConrinrujnicationUlxa^^ _ , 

• Easydeplcyntent 

ICE-T provides scripts and tools for installing and deptoying applications, indude a generalized startip applet 
for providing application launch fron a Web browser or applet viewer. 

• , Centralized authentication of users. 

A custonBzaWe Access Layer, installed on the server, enables centralized control of access to dient programs. 

• Easy maintenance. 

For most enterprises, maintairting existing applications is a tremendous resource burden. ICE-T provides the 
means to make new application front-ends (dients), or migrate existing ones, without changing the architecture or 
programs of the t>ack-«nd (server), or requiring a steep learning curve. 

• Wide use throughout the enterprise, from the desktop or the laptop. A familiar and pen/asive interface. 

End-users can name ICE-T applicatfons as applets in a Web browser. 

ICE-T Applteation Development and Deptoyment 

The primary development task in an ICE-T applkation is to create an applwation front end, a Java Presentation 
Engine, from the provided templata The Presentation Engne (PE) template indudes nDethods to send messages and 
thar data through a dient Communication Ubrary. Devetopers nrwdify the template to specify the nriessages and data 
required for their appfication. The Communication Ubrary handles the passing of messages and data across the nel- 
wortt The Ftesentation Engine Toolkit supports these tasks. The TodWt is a full set of 
you nuist nxxfify or extend. 

An additional development task is to nxxlify the sender program to spedfy which functicMi to call in response to 
irtxxjnd messages and make calls to a server Ccmminication Library to send results to the dient All of tiie compo- 
nents in an ICE-T application system reskle on the senrer. To deptoy an application, you install its components and 
additional ICE-Tffles and programs that manage appltoations on the server. ICE-T also provides a template for aeating 
a startp applet that enables users to start applicaBons from a browser. Chapter 3, "Configuring and Deploying ICE-T 
Applications*^ describes these taste and tools. 
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Event-Drtven Message Passing in ICE-T Applications 

The components of ICE-T applications aeate. send, and receive messages in response to external events. An 
evert is a way off communrating that something has happened, s^ 
in the system environment (a server shukJcwn). 

The ICE-T Communication Layer enatales asynchronous evert-driven message passing l)etween diert and server 
program components on TCP/IP. In ICE-X the messages themselves are events, and each program componert 
includes local handlers for message events. 

aient and server program components must each be set up to aeate, send, and receive messages. Part of the 
Presentation Engine's functionality is to delerrrtne the recipients and deliver the messages to them. f=br example, the 
user interlace sends a message to the Presentation Engine when a user dicks a txittcvi. The Presentation Engine 
receives the message and then either sends it to the data model or the server program, which then performs an oper- 
ation and repi tes with the residt 

The server program must also be able to receive messages and must register functions to handle them. 

The redpients of messages do not need to know much about each ot^ 
th^ want to receive This information is registered using the createMessageHandlers 0 method in the dient program 
and the createMessageHandlers 0 function in the server progam. 

Presentation Engines should include handlers for two kinds of applicatfon events: 

• Events from the user interface 

Events comingJnio the^PreserriPtion Engne from the user interface result in messages to the server or the 
Presentation Engine's data model. 

Events from the server 

Events coming:in-toJr*e Preserrtation Engine from the server result in displaying data in the user interfece or 
putting data in the Presentation Er^ne's data model. 

Server programs should indude handlers for messages from the dient Typically, the handler wouW call application 
logic and send the resulting message and ifs data back to the dient through the server Conwnunication library. 

ICE-T Application Execution 

ICE-T applicatfons are designed to wwk within existing dient-server environments. They differ from familiar dient- 
server applications in some key ways. 

Tn»caIIy diert programs are developed, maintained, and distributed periodically, taking tong cydes of devetopmert 
tirne, and requiring time to deptoy to cfiert nodes. Users who are not on a node on th^ route may miss soft- 

ware updates. Devefopmert can consume resources because of the difficulty of the language or cools used. 

Corrpned ICE-T Presentation Engines are installed on the sender and downtoaded on request through HTTP serv- 
ers. A pair off Communication Libraries behave as a frameworic for executing the application. This communication layer 
handles the marsharmg and unmarshafling off the message data transferred between diert and server. Both dient and 
senw should be prepared to handle shutdown events. ICE-T provides default shutdown handlers for this purpose, and 
devefopers can add their owa 

How iCE-T Applications Wortc 

Before devetoping an ICE-T appTication, you might find it useful to see hew ICE-T ^jplications wortc, from both an 
end-user's perspective and inside ICE-T. 

The User View 

ICE-T applications can use a Java-enaUed Web browser for diert access to application execution. Although devel- 
opers may choose to have appfications launched outside a browser, a Web page presents a familiar and easy to use 
irterface for laundwig applications. 

The user begins b/ opening a Web page and dkidng on the URL for the application she wants to run. The URL is 
the address for a Web page that indudes an ICE-T application startip applet The Web page with the startup ap|:^€t is 
foaded into the browser. The applet oollecls access information from the user. The applet contains the URL of the server 
holding the appBcation components and the application name. This infonmalion is processed on the server. Iftheiiser 
name, password, and chosen appfication are authorized, the server downloads a Preserilation Engine to the usei^" 
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node. 

The Presentation Engine presents the user with an inlerfece for interacting with the server program and data. H also 
determines where to pass messages for handling, either to the server program or to its own data model. One example 
of a cfiert program is one that communk^tes with a server program that 
datat>ase. Such a client program might have these user interface elements: 

• A text field where i^erserter a first or last name that they wish to find In the er^ 

• Buttons for clearing the fields (Clear), exiting the application (Quit), and launching the search (Search) 

• A scrolling window for viewing the resuHs of the query 

The user enters a first or last name and presses Return or clicks a Search Ixjtlon. The client program sends the 
query to the server, where the sender program searches the employee database for a matching name. If a match is 
found, the server rrtums the resuHs to the dient The resuHs are displayed in a window on the dienL 

ThelCE-TViev/ 

When 1 user launches an ICE-T application, the dient node establishes a Web connection with the server node 
using KTTR The server manages this Web connection. ICE-T applications can be launched from a browser, an applet 
viewer, of as standalone applications. Rgure 26 niustrates the steps assodated with launcNng an applicatiOT URL in^ 
accordance with a preferred embodiment On the server side, the ICE-T Access Layer (a cgi-bin executable) authenti- 
cates the user data H the authentication succeeds, the Access Layer contacts the ICE-T Application Manager and the 
Application ^ianager starts the server program and initiates a network session. 

The Application Manager downloads an HTML page with a startup applet for the application. When the us«^ rire 
the stailup applet the AppTication Manager selects a compiled Presentation Engine and downloads an HtML s»ge ^ 
containing the applet tag for it to the dient using HTTP The compfled Presentation Engine indudes a GUI and an 
instance of the client Communication Ubrary and is ready for execution in a Java-enabled browser or anywhere the 
Java Virtual Machine is installed. 

The c^ent node then e)fficutes the Presentation Engine locally. The Presentation Engine makes a TCP/IP connec- 
tion to the server where the server program is ninning, and the dient and server programs cooperate to execute tfie 
appTication. 

When a user interface event occurs-for example, when the user enters a first name in the text fieW and dicte a 
Search butJcn-the user interface passes a message to the Presentation Engine. The Presentation Engine either sends 
the message to its data model for processing by the cOent, or passes the message to the server for processing by the 
server program. The Presentation Engine detennines where on the dient a message is handled based on how you 
have registered message handlers. When the server program sends a rnessage with data to the dienL the Presentation 
Engine displays the result 

The exchange of messages between dient and server is handled through the ICE-T Commurocation Libranes in 
the ICE-T CommuTBcalion Layer. When the dient program tenninales. the Application Mans^er doses the sockrt con- 
nectfon to the diert and terininales any server processes it started. 

ICE-T Task Summary - BuHding Program Components 

ICE-Tte modular architecture makes it easy to dstribute development tasks to multple devek)per&. Alternatively, a 
single devetaper can corr^lete ICE-T devetopment tasks in stages. Devetoping a dient program requires making a Java 
Presentatfon Engine, connecting it to a user interface and to the ICE-T Communicatfon Layer so that it can communi- 
cate with a server program The server program could be an existing program or a new one. It must be written in a lan- 
guage thalcancallCsothatitcan work with the ICE-T Communication Layer. You don't need to devetop new server 
programs for ICE-T epplicatfons. but you must enable the server program to handle messages from the dient 

ICE-T Applk:ation BuiMing Bkxks 

An ICE-T application consists of a dient program and a server program communfoating through a Communication 
Layer. The dient program consists of: 

• A QUI buOt with Java 
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• A Jay^Presentalton Engine buift using a tenplate 

These conponents, and related dasses used by the Presentation Engine, combine to behave as a single client 
under the control of the Pres^itation Engine. The Presentation Engine may be presented as an applet launched 
from an applet viewer a a Web browser, or as a standak>ne application. 
5 The server program, new or existing, is developed however the developer chooses. It must be in a language 

that calls C and it must include functions for handing messages from the dient A template with these functions is 
provided, as is a main routine that makes calls to the provided server Communication Ubmy, 
ICE-T provides these templates, tools, and lft>raries for developing applications: 

10 • pe_template.java 

A tenplate for a worfdng Presentation Engine 

• ICE*T packages (supplementary to the standard Java packages) 

75 • server4emplat&c arvJ serverjtemplate.cc 

Server program terrplates (one each for C and C^-^) that drfine and enaWe message passing to and from the 
dienL The tenrplates can be used with existing programs or used as a starting poirrtlnr deveksping server pro- 
grams. These terrplates are anak)gous to the pejlemplate used for the cOenL 

20 • ICE-T message data types that work the same on tX34h dient and server. 

ICE-T also provides a framework that the devetoper does not nwdify^and in whfch ICE-T.applications can exe- 
cute This framework indudes: 

Communk^ation Layer 

25 Supports network cofronunicatk)n t>etween dient and server pro-ams. The server Communicatk>n Lbrary 

presents a C API to the sender program, whfeh is linked to this Jibrary. The dient Communfcation Library is in^e- 
mented in Java. 

ICE-T ExceptXKi Layer 

30 Provides exception reporting from the ICE-T applk:ation (dierrt and server) iri addition to standard system error 

reporting. 

The Presentation Engine 

35 Every Presentation Engine extends Cir^erits from) a Java dass named PresentationEngine. All of the ot^ects that 
the dient program needs are either in the Presentation Engine dass or caHed by It 
javEi, and caDs the methods that you need to create a working Presentation Engine. 

The filename for the Presentation Engine template is pejerrplat&java You can find it in the ICE-T applkation 
installation directory under Templates/C or Templates/Gi-i-. The file is placed in each c* the Template subdirectories for 
40 convenience. The pejtemplate is the same in both files. 

Figure 27 descri)es the forrns of a Presentation Engine, as an abstrad Java dass, a ^ 
an executable conponent in an appltcatk)n in accordarice with a prefOT 

To create a working Presentation Engine, you copy the pejtenplate file and make these changes: 

45 • Supply your own Presentation Engine nama 

• Create user interface components or map the ones from a Java GUI buiUer. 

• Create a data model Of your application requires dient-skJe processing). 

50 

• Define messages arxi their handlers. 

• Register message handlers. 



55 These Steps are descrbed in this chapter. 
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Presentation Engine Implementation Options 

Developers can aeale Presentation Engines that simply send messages from the user interface to ttie server and 
display ttie data that the serva^ returns on ttie di&ti This option tor Presentation Engine implwnentation is called a 
"PELita" An aftemative in^ementation of Presentation Engine handles some local data storage in what is called the 
Presentation Engine's data model. For the latter, developers are required to implement a aeateModelQ method, 
described in this chapter. Botti options are supported k>y the pejemplate. 

ICE-T Classes and Packages 

The documentation for tiie ICE-T Presentation Engine API is presented in HTML ftmn, like the Java API documen- 
tation, and is accessSsle from the fdlcwing URL: 
f aei/Z/OCE-T Installation Directory >/doc/api 

where <ICE-T Installation Directory )is the nanrw of tiie directory on your system where you have installed ICE-T The C 
and header fines used by ttie server program are in ttie ICE-T installation cfirectory under Server, 

ICE-T Message Data Types 

ICE-T message data types; 

• Can be used to construct ttie data mode! in the Presentation Engine 

• Are available for use in the server program for use in application logic 

• Have analogs on both the client (Java) and server (C) 

• Use t>asically the same APIs on bottitiiedient and server 

• Can contain only other ICE-T da:^ types 

• Are used in messages from dient to server, and server to dient where ttiey will appear as a 1^ 
th^'r analogous type. 

The table appearing below describes ttie primitive ICE-T message data types and their analogous types on dient 
and server. The prefixes Pe and Srv are provkled for your convenience in rmnfii They are handled as ttie same 

type by ICE-T 



ICE-T Message Types (Primitive) 


Data Type 


aient{PE) 


Server (C) 


Petbar. SrvChar 


char (Unicode) 


char(C) 




16 bits] 


8bHs 


PeString, SrvString 


string 


char* 


PeBodean, SrvBodean 


Boolean 


int 




16bits 


Ibyte 


Pelnteger, Srvlnteger 


int 


int 




32bHs 


32bHs 


PeLong. SrvLong 


long 


long 




64bHs 


64 bits 


PeFloat, StyRoat 


float 


float 




32 bits 


32 bits 
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(continued) 



ICE-T Message Types (Primitive) 


Data Type 


aient{PE) 


Server (C) 


PeDouble. SrvDouble 


double 
64 bits 


double 
64 bits 



1 . ICE-T transmits only the ASCII (8 bits). 

ICE-T supports a conposite data type based on the Java vector dass {java. util.Vector). It differs from the Java vec- 
tor type in that H provkles an inplementation that works on both skies of ICE-T application (Java dients and Cor 
C++ server programs), and it only takes ICE-T primitive data types. 



Table IGE-T Vector Type 


Data Type 


Descrption 


PeVedor. 
StyVedor 


A collection that implements a variable^ength array. 

Add elements sequentially with the add Bement 0 method. Access an element by its indejc 



Wo^ng jrlth the ICE-T Dlrertory Structure 

BeftM-e developing gpplicalions. copy the provided templates and Makef fles to an application devekpm^at dredory. 
There are two subdirectories of templates. 



• <ICE-r Installation Directory yTemplales/C 

Contains Exanple. ntK pejerrplata java. and server_ternplate.c. . , „ . 

• (ICE-T Installation Directory VTemplates/Cplusplus 

Contains Example .mk, pejtatplate. java. and server Jemplate. cc. 

Rx exanple, create an applk»tion directory for an appHcation named myAppName in which the server program is 
written in Oh-, andcopy thetcvrpiatesto it 
% rrMIr myAppNams 

% do (ICE-T Installation Diredory VTemplatesA^Kr (ICE-T Installation Directory VApplicationsMiyAppName/. 

The ICE-T instanation scripts and MakeHierarchy depend on the newly aeated application directory being two lev- 
els befow the lCE-Tinslallation<firectory. If you choose not to follow the diredory setup sugge^ 
will have to sipply options or arguments indicating where the ICE-T installation directory is in relationship to the direc- 
tory you have aeated. 

Designing the aient Program 

Here are some design decisions to make before you develop the dient program for an ICE-T application. 

• Using a graphical user interface (GUI) toolkit specify and design the user interface 

• Determine the events the cOent and server components of the applkation shoiid handle. Name each of these' 
events and associate data ¥«th it In this step you answer the questfon 0* ^ 

the Presentation Engine and the user interface and bdween the Presentation Engine and server. 

• Decide what application logk: to put in the dient program, if any. 

Decide what if any, data processing you want the dient program to handle. TTiis affects virfiether you aeale 
event handfing for data updates in the Preserrtation Engine or just use the Presentation Engine as a mediator 
between the user interface and the server data (a "PE Ute"). 
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• Specify how the user irterface should be updated when th^ 
the server. 

• Specify how the PreserTlatk)nEngme receives arid decodes^ 
later retrieval or displays the data directly. 

• If you choose to store data in the Presentation Engine, specify how it is to be stored and updated and what other 
components in the application deperxl on 

that data. Developing the User Interface 

You can create the user inteiface for the ICE-T application at the same time as, or before, you create the Presen- 
tation Engine. Even though they can be separate, the Presentation Engne and user interface work together, so the 
interactions l>etween them should be planned. 

Creating a Presentation Engine 

Create a Presentation Eng ne involves the following basic steps that are described in detail throughout this sectfon: 

1 . If you have not done so already, copy one of the Templates subdirectories to the Applications directory. 

The ICE-T installation directory includes a oomnuinicalion direcloryjor de^eAop&s to use. To create applica- 
tions, make a subdirectory under applications for each ICE-T application you develop. 

2. Modify and rename the pe_plate file to suit the application. Use the sanoe name for the dass and the file. 

3. Create a Presentation Engine dass. 

Create your own Presentation Engine definition using pe_template.java. 

4. Integrate the Presentation Engine with the user interface (GUI). 

Create a separate user interface dass using your chosen Java tool, integrate the GUI with the Presentation 
- Engine by inplenwnting the CTeateUI() method that is found in pejtem^ 

n/Voridng with the ICE-T Directory Structure* descrtoes how to implenient createUIQ. 

5. Deterntine and define the message events to be passed between the Presentation Engirte and server program 
and the Presentation Engine and user interface. 

hfame each of these events and assodale data with it Specify the type of data ^ 

to each niessage event 

a Add handlers for events on GUI components. 

Inplemert the operations you wart the applicatfon to perform in response to user irterf^ 

b. Write the code lor handling inconrring message events In the Presentation Engine. 

D^ne handlers in the Presentation Engine for inconrang messages from the GUI. Define handlers in the 
Presentation Engine for incoming messages from the server. 

Developers can choose to write a separate dass, or dasses, in separate files to handle events. This 
means that a named handler can be nKxW ied without modifying the Presentation Engine framewori^ itself. 

6. Register which handlers will be sent which messages when events occur (map messages to handlers). 

Specify what hander should receive each message. 
"Registering Handlers" descri>es this step. 

7. BuiM the Presentation Engine. 

ICE-T provides a makefile to build both server and diert prograns. 

These activities are analogous to the tasks for modifying server programs to woric with dients. In both dient and 
server pro-am cases, ICE-T provides templates with methods (Presentation Engine) and functions (server) for regis- 
tering handlers. Developers provide only the applicatkxi-specific messages and data. 
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Creating a Presentation Engine Class 

Copy one of the Tenses subdrectories to the Applications sutxfiredory. TTiere are tm subdirectwies. one for C 
and one for C++. f=br exanple. create a directory for an application named myAppName If the sender program for 
5 myApprrame Is to be written in C. copy all of the fOes from the Tenplates/C directory: 
% tnkair myAppName 

% cp OCE-T Instaltetion Directory )/rempMes/Cr 

(ICE - T Installation Directory VApplications/myAppName/. 

For each Presentation En^ne you create, modify pejerrplate-java to declare a dass that extends the abstract 
10 Java class PresentationEngine: 

public dass myPresentalionEn^ne extends PresentationEngine 
{// methods for your application 

^ Note - Be sure to give the dass and the file the same name. For example, if the Presentation Engine dass is named 
15 myPresentationEnqine, the file shoidd be named myPresentationEnqina java. 

pejenplala java contains the dass and method declarations ttiat you implement to provide the functionality you 
want 

The methods must irKlude: 
20 • aeateul ( ) 

• createModelO 

• createMessageHandlers 0 

• tnitializeApprication 0 

Implementing aeateModel 0 and inttializeApplication 0 is optional. 

YcHJ do not have to use initiaIize.AppliGatk)n 0 unless your dient program requires local initialization before commu- 
30 nication is started. 

Importli^ Packages 

The pejtenplate imports the appropriate packages, irxduding these ICE-T packages and standard Java packages; 

35 

• sunsofLic&pe 

• sunsofLice pe 
40 • jao^net 

• iava.k) 

• iava.^3plel 

45 

iava.util 

• iava.awt 

so The Java language package (javaJang) is implicitly used and does not have to be explicitly imported. 

To indude fha required packages, a Presentation Engine dass must have ttiese import statements. Doni delete 
^ tiiem from the pejemplate. 

import sunsoft k^ape. ; 

55 

import java.n^*; 
import javakx ; 
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import Java .applet^ 
import javautil. *; 
5 import java.awt*: 

Integrating the User Interface with the Presentation Engine 

ICE-T applications must make user interface elements from the application GUI available as components that the 
10 Presentation Engine can access. The Presentation Engine reads and handles data from events in the user interface 
and updates the user interface with data returned from the server. 

Creating a GUI that is separate from the Presentation Engine, offers developers more flexibility because ifxlates 
to the GUI do not require major changes to the Presentation Engine. Use the aeateUI ( ) method to make the GUI com- 
ponents available to the Presentation Engine 
IS To implement the createul ( ) method with application-specific operations, write a body for the method in whfch you: 

• Declare variables for ihe user interface elements 

• Createaframetc hokJ the GUI applet (optionaQ 

20 

• instantiate and initialize the GUI applet 

• Get the user interlace components 

25 • Provide initial values for fieWs in the GUI (optionaO 

• Add the GUI elements to a Container object (provided in the PresentationEngne dass) 

For example, here is excerpted code from a aealeUI ( ) method that dedares variables for labels and text f iekte. 
30 creates a frame, and adds the user interface elements to a container component defined in the PreserttationEngine 
class. 

protected, void creatcUI 0 { 

35 

Label labeU, labeL2, labeL3; 



40 



45 



SO 

j 

1 
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TextField textFiddJ. textField_2. textFicld„3; 
//... additional variables 

fr = new Frame fMy Application Title"); 

fr.add reenter^, ui); 

fr.pack 0; fr.showO; 

//... 

textPieldJ-selTact C 
textField-2.setrc3rt f 

//... 

uiContainer^dObjcct r firstName'rtextPieldJ); 
uiContainer.addObjcct f lastName^ teictField^2); 

//... 
) 

Creating a Data Model In the Presentation Engine (Optional) 

Updates to the cfiert program can t>esert to the user irterfaceo^ in the Presentation En^nalf 

your application ts designed to hold data in the Presentation Engine, you use the aealeMode! ( ) method to create the 
data objects (Observables) to hold the data and altach Observer object 

createMode! 0 is optional and is commented out in the pejemplata To use or 

• Uncomment the method in the Pejemplate 

• Create Ot>sen^e data objects to hold data from the server 

• Attach Okiservers to the data ok^ects. if necessary 

• Put the Otjservable data objects into the data model 

This exairple instantiates a PeVector date object named empveclor 
is descnbed in 'Attaching Ot^sen^ers to Data Ok)jects.'' 
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protected void createModel () ( 

/ / create the observable 

PeVector cmpVector = new PeVectorO: 

/ / Attach observer to the observable 

empVector. addObserver (new empObserver (model)]: 

/ /put the obscrvablcs into Model 

xnodeL addObservable f cmpVector^, cmpVector); 



Attaching Observers to Data Objects 

Devetopers haw the option of drfining any data obje^ 
in messages) a as a PeObservable, a data rtem with a method assodated ^ 
an associated PeObserver function that is called when the dala^i^ 
the applicalk)n to notify any program components that depend on t^^ 
able and you attach a PeObserver to it 

ICE-T provides the peObservaWe and PeObserver dasseSw Developers call the methods in these classes to add 
observable data objects to the model and add heir observers to an observer lis^ 

Handling Events 

IGE-T dient programs receive messages in response to external events. Qient program developers need to specify 
what messages they want the Presentation Engine to receive and register this Information using the createMessage- 
Handlers 0 method. Server program developers have the ar^alogous taskof d^ing message handlers and registering 
their handlers. 

ICE-T provides a layer of abstraction to handle interactions between the GUI and the Presentation Engina This 
layer is called the Ul Adaptor and it is a set of Java classes that develcpers use as given. The Presentation Engine 
makes calls to the Ul Adc^rtor to register messages. The Pe Jtemplale includes the necessary methods; developers pro- 
vide the message bodies as descrft>ed in the procedures in this chapter. 

Presentation Engines handle two kinds of appfication events: 

• Events from the user interface 

Events conting in to the Presentation Engine from the user interface result in messages to the server or the 
Presentatk>n Engine's data model. 

Events from the server 

Events coming into the Presentation Engine from the server result in (fisplaying data in the user interface or 
putting data in the Presentation Engine's data model. 

Handling Events from the User Interface 

AppGcations handle user irterface events, such as button dicks and teod entry. Java prov^ 
for associating actions with events, such as those on user interface components. 
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public boolean action(Event cvt. Object arg) { 
5 / /... 

} 

10 

Typical behavior for an action 0 m^hod is to gel the data fronri the user interface event and send a nriessage to 
consent ol an application that is designated to handle it In an ICE-T application, those messages are sent to the 
Presentation Engine using the sendMessage 0 method. 

Here is an exarrple of an action 0 method when in a GUI. ft handles an event in which the user dicks a '^Search" 
15 button after entering a text String' 

public boolean acaon(Event evt. Object arg) { 
//-• 

if (arg. equals f Search")) 
I 

System-outprintlnrSearch event is detected'); PeString firstNaine 
= new PeStiing (cntry_LgetText 0(): 

PeMessa^ msg = new PeMessage fScarch"); 

msg. addDataElement (firstName); 

PeDebug,printlnr====> msg is: "+m5g); 

/ /send this event to the UI adaptor 

40 

pc-sendMessage (msg); 



45 

i 



return true; 

50 



55 The action Q method serxte the message defined in: 

PeMessage nreg = new PeMessageTSearch^; ^ ^ ^ ^ 

The PeMessage dass encapsulates the message name and the data The data in this message, added by the iadd- 
DataElem^ 0 method, is a first name The sendMessage 0 method sends the message and its data to the Presenta- 
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tion Engine through the PeUIAdaptor. a dass that ICE-T provides for handfing communication between the user 
interface and the Presentation Engpna Developers do not need to modify PeUIAdaptor, Ixjt do call methods in it as 
directed the pejemplate. 

5 Handling Events from ttte Server 

Events from the server program that generate messages for the dient can be handled by: 

• Updates to the user interface 

10 

• Updates to the Presentali<wi Engine data model 

Write a handler for each ev^ from the server. Include it in the same f fle as the Presentation Engine, or a separate 
dass fila H you use a separate file for the handler, r^nember to define it with public access. 

15 

Creating Hancflersfbr Updates to the User Interface 

To aeate a handler that updates the user interface, use the template to define a dass that extends PeUIHandler. 
PeUIHancfler is an abstrad dass for a handler of messages that are sent to the user interfaca 
20 The constructor method in PeUIHandler provides access to the uiContainer for updating the user interface and for 
sending messages using the uiAdaptor. . - . 

This exanple from the pejemptate showre the d^inition for a dass named SampleUIHandler. The construdor 
method passes adaptor and UiContainer as arguments to give your execute method ac^^ 

Use tKs d^ffiition as is. but supply the nanie of the dass and add the body d the exe^ 

25 

dass SampleUIHandler extends PeUIHandler { 

public SamplcUIHandlerfPteUlAdaptor adaptor. PteUI uiContainer) { 

30 

super (adaptor, UiContainer); 

» 

35 pubUc boolean execute (Object caller, PeMessage message) { 
//decode the record sent by the server 

40 

//update the ui 
return true; 

45 

) 



To enable the Presentation Engine to knew what messages to send to SampleUIHandler. register the name of the 
handler and the data it handles. This step is described in "Registering Handlers fcx Updates to the User Int^ce". 

Creating Hamflers for Updates to the Model 

Messages from the server can be handled with code that updates the GUI (as in the example above), or code that 
stores the data in the Presentation Engine. If you used the createModel 0 method, you have to create handlers for the 

events that affect the model. 

To create a fmndler that updates the model, use the template to deHne a dass that 
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• Extends PeModelHandler. 

PeModdHandler is an abstract dass for a handler of messages that are sent to the data model you defined 
with aeateModel ( ). 

• Uses the conslnjctor of peModelHandler as is, except to use the new dass name in place of PeModelHandler. 

public PeModelHandler(PeModel model) 0 

This constructor passes the model dass as an argument so that your Presentation Engine has access to the model 

dass for updates. 

This example from the pejenplate shows the definition for a dass named SampleModelHandler. Use this def ini- 
tion as is, tiut supply the name of the dass and add the body of the execute method: 

class SampleModelHandler extends PeModelHandler { 

public SampleModelHandler (PeModel model) { 
super (model); 

) 

public boolean execute (Object caller, PeMessage message) { 



/ /Application code that decodes the record sent hy the server 
/ /Application code that updates the model 
return true; 

J 

} 



Registering Handlers 

Register what conponent handles what messages in the Presentation Engine ty fflling in the aeateMessageHan- 
dler 0 nnethod. 

CTeateMessageHandler 0 is d^ffied in the pejemplate to register handlers with either the user interface or the 
model. Use this method as d^ned. changing the arguments for adding hancflers to supply the names of the messages 
and handlers you defined. 

Registering Handlers tor Updates to the User tnterfeice 

This code snippet from the Pejemplate fllustrates how to register the handler defined in the example in "Creating 
Handlers for Updates to the User Interface". 

Note that you just use the code in the example as is. \bu doni need to specify anything other than the names of 
the messages and the objects that handle ttient For each handler you 
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0 method Change the arguments to the uiAdaptor.addHandler 0 method to specify the names the messages and 
handlere you d^ned. In this example, the name of the message is "sample_ui_message" and the name of its hander 
isSampleUIHandlerO: 

protected void createMessageBandlets ( ) throvd 
DuplicateHandlerException ( 



uiAdaptor-addHandler | "saunple_ui.me»sage-. 

new SamplcUmandler (uiAdaptor. ulContaincr) ); 

uiAdaptor and uiContainer are d^inei by the PresentationEngine dass. >bur handler needs to pass them as argu- 
ments so that Its execute method has access to the user interface elements (GUI components). 



Registering Handlers for Updates to the Model 

If the message is to be handled in the Presentation Engne's data model, register the name of the handier in the 
25 model. This code is defined for you in the pe.Jtemplate. 

This code shwet illustrates how to register the handler defined in ''Creating Handlers for Updates to the Model". 
Use the code in the sxarrple as is. Change the names of the messages and the methods that handle them; 



30 



protected void createMessageHandlers {) throws DnplicatcHandlerEKception 

{ 

modeL addKandler fsample.modeLmesaaBe", 
new SampleModelHandler (model)); 

//.» 
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45 Handling Shutdown Events 

ICE-T provides default shutdown hanCBers. The shutdown handlers are defined in the PresentationEngine dass, 
not in pre Jenplale. Developers who do not want to accept the defaift shutdown handling can write their own shuttJown 
handlers. A new handler takes precedence over the previous handier for the same message name. To add a new han- 
50 dier. developers: 

• Write the handler 

• Use the same message name flCET.SHUTDOWN") 

55 

• Use the methods provided for registering handlers in the Presentation Engine and the server program 

When a shutdown happens, the Communication Ubrary notifies the application by means of the shutdown han- 
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(Here. ShuWown handlers are identical to other message handlers, but have a preset message name 
("iCET_SHUTDOWrr). To regfeter a shutdown handler, the application code makes a call to addMessageHandler 0 
using the preset message nama 

5 Registering Shutdown ttoidlers in the Presentation Engine 

An application can register two shutdown handlers in the Presentation Engine, one with the Ul Adaptor and one 
with the model. Registwing shutdown handlers in the Presentation Engine is optional. 

To register a shutdown handler on the uiAdaptor, use the following call: 
ic uiAdaptor.addHandler nCET_SHU7DOWir, new 
shutdownlfendlerUI (uiAdaptor, ulContainer)); 

To register a shutdown handler on the mode], use the following call: 
model^ddHandler nCETjSHUTDOWN", new shutdownHandleiModei (nfKxIel)); 

IS Registering Shutdown Handlers in the Server Program 

Your application can register one shutdown handler with the sender program. 
To register a shutdown handler in the server program: 
SrvCommjaddlWessageHandler nCET_SHUTlX>^ 

20 <functionPolntefToShutdownHandler>); 

Provide the name of the fmction that executes when the shutdown occurs. ^ . ^ 

((functk>nPointefToShutdownHandler)in the example above). 
Preparing the Server Program for Communication 

25 

To prepare the server program to comrrwrtication with the client program, the developer J^plugs in" the server pro- . 

gram to ICE-Ts Con¥nunication Layer. Connecting the server pro-am to the sewer Communication Ubrary. which is 

part of the ICE-T Conminication Layer, is an^ogous to connecting the GUI to the Presentation Engina In both cases. 

developers enable the exchange of messages, and these messages are handled locally by the components -the serve; 
so prc^ram component and the Presentation Engine component 

The server program conponent in an ICE-T application nwst be written in any language that can call the C prc- 

granwrtng languaga ICE-T provides both C and C<-i- language templates for handling messages and making calls to 

the server Comrnunication Ltorary. Use the appropriate teniplat^ 

template functions to an existing sender program. 
35 Note - if you have not done so already, copy one of the Templates subdirectories to the Application siixfirectory. 

There are two subdirectories, one for C and one for C++. Each directory contains a server Jemplale, one for C and the 

other for C++. 

To enable communication between the server program and the client program: 

40 • Create message toidlers in the server program that are analogous to the message handlers you created in the 
Presentation Engina This step is descnl>ed In "Handling Messages in the Server Program". 

• Make calls to the ICE-T server Communication Library. 

45 The server progam tenplates provide functkxis for messs^e handling and communication. Devetopers just supply 
the appTication-spectnc message names and their handlers. For C servw programs use server-template. C. For C++ 
programs use sen/erjemplatacc. The tenplates are in the ICE-T installation directory under Templates/C and Tem- 
plates/C++ respectively. 

Each server program tenplate calls a defeutt main routine. The default main 0 routines are provided for conven- 
50 ienca If you choose to write your own main 0 routine, took at default_main.c or defaurtjnaiacc for guidance and follow 
the steps in "Mocfifying the Default main Routine (Optional)". 

Figure 28 describes the fuxrtions developers nwstffll in using the server program templala All three return integer 
values of 1 (TRUE) or 0 (FALSE). A retum value of 1 (TRUE) indicates that the applicatfon startup can proceed. A return 
value of 0 (FALSE) indicates a problem that results in stopping the appfication. The remaining functions in the server 

£5 program templates can be used as provided. 

Figure 29 illustrates Server Properties in accordance v«th a preferred eriibodime^ 
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HandDng Messages In the Server Program 

In developing a Presentation Engine, a key task is writing the code that hancfles messages. The same task is per- 
formed for the server progranrt tt consiste of sinrtilar steps: 

5 

• Write the code that handles incoming events (typically requests for data) 

Register the event handlers 

10 To handle messages in the server program: 

1. Write a function to handle each incoming nr>essage. 

Each functk>n you write takes one argument, a SrvMessageQ function, and has a void return type. 

The function should extract the data from the message, and then call application logic to process rt a send a 

15 message back to the dient 

Fbrexan^e. here is a handler function in C that responds to a message with the data; employee name (emp- 
Name) and enrpksyee nimit>er (empNumber): 
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void handleEmpIoyeeRecord (SivMcsaage ^message) ( 

SrvDaca *tmpHame: 
SrvData 'empNumbcr; 
char *naine; 
int num; 

/* 

* disassemble incoming data 
V 

empNaroe" SrvMessage^getDataEiement (message. 0 ); 
empNuinber»SivMessage_getDaia£lemeiit (message, 1 ); 
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namc-SivString^etValue (empNaxne); 
nuxn 55STvInteger_getValuc(empNunibcr); 

* Now process the data... 
V 

lookupEmployee (name, number); 

Here is the handler function in C++: 

void handldEmpIoyeeRecord (SrvMessage ^message) { 

* disassemble incoming data 

V ' 

StvData *empName« measagogetDataElement (0); 
SndData •empNumber=message >getDataElement (1); 

char *name=empName >gctValue ( ); 
int num '=empNumbcr->gctValueO; 

/* 

^ Now process the data... 
V 

lookupEmployee (name, number); 



2. Resister the message handlers. 

Fill in the createMessageHandler ( ) function in the server-template to regsler the handlers with the server Com- 
munication Ulxary. 

1^ that you just use the code in the example as is. \bu dont need to specify anything other than the names of 
the messages and the functions that handle them. For each handler you register, add a 
SrvCommjadtWessageHandler 0 call. The arguments to the functions in this example are the appfication-specific 
names of the messages and handlers you defined in Step 1 . 
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int createMessageHandlera 0 { 

SivComm_addMes5ageHandler fDouble', handlcDouble); 
SrvComm_addMessagcHandler rfirstNaxneEntered", handleSearchMcssage); 

//... 

return 1; 

) 



Modifying the [>effaun main Routing (Optional) 

Once the server component of the application includes definitions for how it handles messages and registers those 
handleru it can call the senrer Communication library. Those calls are d^ned in the default main routines provided t)y 
ICE-T: default_main. c and defaidt_maia cc. 

c;efeult_main. c and default_main. cc are in the IGE-T installation directory under Server/Main. ^ , 

This section descrt)es the order and usage of the calls to the sender Communicalion Lftxary. 

If you aeate your own main or modify the default, follow the instnjclions in this section for including the calls that 
enatie tha sender proyam to work with the 1GE-T Cornrnunicalfon l^er. 

To connect the server program to the Communication Lilrary: 

1 . Include the ICE-T header f Hes. 

The default_main files include the header files already: 

#include "SrvData-h" 
. #include "SrvComm.h" 
#include "SrvMessagah" 

2. Call creale_SnOomm { 1q)" ) to aeate the Communicalion Library's data sbuclures. 

char *protocoI="tcp'*; 
aeate_SrvComm(protoool); 

3. Call srtSn<}ommProperties 0- (Optional) Set sender properties. The se^n^Commproperties 0 function is typi- 
cally inplenriented in a separate file that is Tinted to the sen^ program as p^ 

4. Call createMesss^eHandlers 0- 

See "Handling Messages in the Server Pro-am" for information about how to use oeateMessageHandlers ( ). 

5. Call SrvCommjcrealeSockBl ( ) to aeate the listener soctet and output the port number. 

Note - Do not write anything to stdout before you mate the SrvComm_aeateSocte(t ( ) call. 

6. Inrtialize the application. 

7. Call SrvCommjacceptaientConneclion 0 to accept the connection from the dient 

Mote that the order of Step 7 and Step 8 may be interchanged. 

a Finally, call Sn/Comm-slart 0 to slartthe Communication Ltorar/s loops. 
This routine does not retuiTi until everything is finished. 

Building ICE-T Applications 

Bulking an ICE-T application consists of modrfying a mate fne for the cOert^ using 



EP0844 558A2 



it to make both programs. 

ICE-T proves a mak^Be (Exarrplamk) fa both the Presentation Engine and the server programs. ExafTple.mk 
is in the ICE-T installation directory under Tenplates/C or Temp!ates/C++. These files are copied to the/Applicalions 
directory. 

To use the makefile. nrKXlify it to specify the: 



• CofTpiler kxation 

• LftMBries kxHtion 

• ICE-T installation directory (optional) 

• aient and server source file locations and names 



1 . Open Exanplarnk in an editor and ioHkw the instructions in the f ila 

2. Supply the locations of the compiler, libraries. If you have moved the ICE-T installation directory, supply its new 
location. 

There is no need to change the location of the ICE-T installation directory. If you choose to move il. supply the name 
of the location in the TCET-INSTALL - DIR maaa 

The macros for which you provnde values are shewn betow as indicated in the code: 

### Environment Configuration ### _ — » 



# Change the following lines to indicate the location of your compiler. 

COMPII-ER_BlH= 
COMPlLER.LIBs 

# 

# Change the following line to indicate the location of the ICET installation 

# directory (either absolute or relative to the current directory). 

# The defavdt value (-7-) allows you to build an example in-situ in the 

# installation hierarchy. 
# 

ICET - INSTALL - DIR=»/.. 

3. Change the macros for the Presentation En^ne source files. This example specifies the Java files for the Pres- 
entation Engine tenplate (pe Jenplate.jav^ and a user interface file named myOii-iava. The macros for which you 
provide values are shown here in bold type. Change the names off the f Ses to those used in your application: 
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#«#####«#«####«##«««####### 
### PE ### 

### (Configurable Macros)### 
########################### 

# 

# Change the foUowijig macro to add your Java files 
# 

PE_S0URCES. java= \ 
myGuiJava \ 
pe_teiiiplate.java \ 
#end 

# 

# Change the foUowing macro to indicate which of the Java classes # is the top 
level class (Lc. the subclass of presentationEngine) . 

# Note: specify this class without any extension^ e.g.: 

# PE_MAIN_CLASS^yPresentationEngine 

# 

PB_MAIN.CLASS«T>e_template 

Exanplamk specifies files for the server program templale (server Jemplate). The macros for which you pro- 
vide values are shown here in boWtypa There is a macro for C source ffi^ Change 
the names of thefiles to those used ly the server program in your applicalion: 
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####«#«##««####««####««»###### 
### Server ### 
* ### (Configurable Macros) ### 
################«############ 

# change the following macro to add .cc (C Plus Plus) fUes 
# 

'5 SERVER„SOURCES.CC=\ 
#end 

# 

20 # change the following macro to add x (C) files 
# 

SERVER30URCESX'\ 
26 default»main.c \ 



server^templatc. c \ 
tfend 

# 

# change the following macro to indicate the name of the 

# server executable 
SERVER - ServerTemplatc 



BuikJ the cfient program with the following command: 
% make -f Example-mk pe 
Build the server program: 
45 % make -f Example.mk server 

Both pe and server are defined for you in the Makefile. 

Testing ICE-T Applications 

50 \bu can test the Presentation Engine atone or with the server program. \bu have to build the programs before you 
test them. 

• Run the Presentation Engine dass by itself using the java commarxJ. 

55 For example: 

% Java myPresentationEnglne 

To test the Presentation Engine with the server program: 
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1 . After you have made the server progran^ run rt to get the ^ 

This example shows the result of running a server program named myServer: 
%myServer 

// ICE LOG nrtessages deleted from ttts example. 
37526 129.146.79.147 

ICE: .ApfrficationServer: port=37526 ServerlP=129.146.79.147 

2. Supply the server machine I P and the port id as arguments to the java command. 

For example, i^ng the machine and port id from Step 1 : 
%iava myPresentationEngine 129.146.79.147 37526 

3. To test the Presentation Engine In debug nrxxle. use the -debug option to the java command. 

The - debug option should be the first argument after the dass name: 
%iava myPresentationEngine - debug 129. 146.79. 147 37526 

Configuring and Deploying ICE-T Applications 

In addition to tools for developing a Presentation Engine, ICE-T provides these components to support application 
deployment execution, and adnvnistration: 

• Installation scripts 

The following installation scripts are in the ICE-T installation directory underAwn; 

• ice-httpd-setup 

Sets up the directories you need on the server. 

• tce-install-aocess . - . 

Installs the Access Layer on the server. 

• ice-app-insteill 

Installs each compiled Presentation Engine and server program on the.sen^er 
AccessLayer 

Acts as gatekeeper for HTTP communication between the client and server nodes. The Access Layer is a cgi- 
bin executable that identifies and authenticate users. You can modify the e files used by the Access Layer and then 
use the suppfied makefile (Access.nf^ to build a cuslonrazed Access program for use with ICE-T server applica- 
tions. 

• Application startup applet tenrqslate (Java) 

A teirplale for making Java applets that launch ICE-T applfcations. The template is in the ICE-T installation 
directory under StartAppleL 

Web server (user must install) 

Sufiports HTTP connections; enables Web access and the use of a browser front end for executing an ICE-T appli- 
cation. 

Note - Sun internal users can install the Web server from /homertnternel/CERN/htlpd/. The directory contains a 
README file wHh installation instructions. 

Depksying and maintaining ICE-T applications involves these steps: 

1 . Using a stamp applet and HTML pages to launch ICE-T applications 

2. Setting up tiie Web sender 

3. Customizing (optional) and installing the Access Layer 

4. Running installation scripts for Presentation Engines and server programs 

5. Configuring application management files 
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Using Startup Applets and HTML Rles 

COTpfled Presentation Engines can run as applets in a Java-enabled Ijrowser. To enable users to launch ICE-T 
applications from a iM-owser use the named ICE-T temptettes to: 

• Create a startup applet tor each application. Use the startAppletDevlR. java template 

Using the Startup Applet" descries this step. 

• Create a top-level HllWL file with Brte to each application. This file senses as a "splash page" identifying the appli- 
cations available and including links to an HTMLffle for each application. Use splashTemplatahtml. 

"Creating a Top-level H^L Rle" descrtoes this slepL 

• Create an HTML f Be for each application. Use appTemplatahtml. 

"Creating Individual Application HTML Res" descn*bes how. 

Using the Startup Applet 

A startup applet provides a way to launch an ICE-T application from a Web page. The slarti^ applet: 

• Starts the HTTP access to the server 

• Authenticates the user 

• Starts the server program 

. Downloads the Presentation Engine as an applet to the Web page a opens the applet in a separate user interface 
window (developer's choice) 

You can use the startAppletDevlRjava template to launch the applications you build, or aeate your own applet The 
tenplate is conpletely generalized so that rt can be used for any of your applica^ 
in a separate parameter to the applet tag. {See "Creating Individual Application HTML Files".) 

A conplete code listing for startAppletDevlR. Java is in Appendix B. 

By default, the startup applet opens the Presentation Engine in the same window. To have the Presentation Engine 
appear in a new browser window, open startAp-lelDevlR. java and Wlow the instruction in the file: 

AppletContext cent = app^qetAppletContextQ; 
if(contHnuU){ 

System-crr.println ("Showing document: [''+newURL+"] "); 
cont.$howDocxunent (newURL); 

r 

* To shorw the applet in another window, replace the 

* the line above with the coratnented line below. 
*/ 

/ /contshowDocument (newURL), -new_window^ ); 

} 



Creating a Top-Level HTML Hie 

\bu need a a top-level KTMLfile, or "splash page." to present the list of available applications with links to the appli- 
cation-level HTML pages for them. When a user chooses a fink, the link takes them to an appficalion-level HTML page. 

ICE-T provides a defaUt HTML file for the "feplash page." The file, called spUashTemplatehtml. is in the ICE-T 
installation directory under StartApplel You can use the default file or ntake o^^ 
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To create a tojHe^e! Web page for fisting the finks to your appfication Web pages: 

1 . Copy splashTemplataritml to another file. For exanple: 
% cp splashTenrptate.htm) myAppSplashPsagahtnil 

2. Open the file In an editor. 

3. Provide a title for the page and any text you want to include about the application(s) listed there. 

4. Supply the nan--e and the URL of the application-level HTML page for each listed application. 

For exairple. if you used appTememplat&htinl to aeate an HTML file for an application named MyApplicationI: 

<htinl> 



<a hrei^"MyApplicationl-htinl"> 

MyApplicationI 

</a> 



=/htinl> 



5. Copy the file to the appropriate location on your Web server. 

The resuft is a Web page wHh a link to the nanoed appfication: 
MyAppTicatior^ 

When a user chooses this link, the browser k>ads an application-level HTML page witti tiie slartif) applet for the 
applicatiort 

Creating Indhddu^ Applteation HTML RIes 

Think of the application-level HTML file as the Presentation Engine startip paga This page contains the startup 
applet tiiat results in the Presentation Engine being downtoaded. 

When the user launches the stamp applet, the startup applet takes the name of the application from the applet 
parameter, the user name, and the password and sends these using HTTP to the Access Layer on the server. 

To create an appfication-level Web page: 

1 . Copy alDIDTemlDlalahlml to another file. For example: 
% cp appTemplate.html myAppPage.html 

2. Open the file in an editor. 
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3. Include instructions to the us^on how to launch the appOcation. (Optional) 

startApplelDeviaiava <«ines a Send button and a dass (sendBtn) that handles the user's input appTem- 
platahtirf indudes detoftinslmclions for using Send. If you want to ctenge the user^ 
applet, you would need to change the sendBIn dass and the in^ructions in appTempIate html. 

4. Specify the name of the startup applet 

H you have copied slartAiDiDletDevlR. java. given "it another name, and compiled it, supply that name to the 

applet tag: 

(applet code="startAppletDevlR.dass" width=400 heicJht=400 > 

5. Provide the applicatk)n name as a parameter to the apple* tag. For example: 
<param nameWVppName value = "MyApplicationI'} 

6. Provide the name of the access program to use for this application. The default value Is "Access.' You may have 
customized the defeuilt access fae and given it another name. If sa provide the name as a value to the Access 
parameter. 

(param name=Access value=" Access" > 

Be sure that the file you aeate from appleTemplale.html contains the end applet tag (fapplet). 

Here are the tegs for a minimal HTIVIL file using slartAlpplelDevIR, an application need "MyApplicationr, and the 
default access program name: 
(html) 

(blockquote) 

Please provide Usenriame and Password and press the "Send" button to launch tt^^ application. 

(/blockquote) 
Qv) 

(applet code="startAppletDevlR.dass" width=400 height=400) 

(param name=AppName value=''MyApplicationr (param name= Access value="Access") 

(/applet) 

(/html) 

When the user launches the startup applet and sends the user date and the application name to the server, ICE- 
Ts Access Layer: 

• Authenticates the user name and password 

• Downloads the Presentation Engine as an applet in a Web page 

As part of the process of delerrtrting access and downloading Presentation Engines, the Access Layer relies on an 
application configuration fOe to provide information about the location and names of program components ICE-Ts 
Access Layer installation script generates the application configuration file automatically. That configuration is the basis 
for generating an HTML wrapper file in which to dowrtioad the Presentation Engine. You can accept the defaiJts and let 
your application use the generated HTML wrapper, or you can customize the appTication configuration file so that it gen- 
erates a customized HTMLfile to hold the Presentation Engina See "Configuring Applications' lor more infonnation. 

Setting up the Vlfeb Server 

Note - Complete the following Web server setup before installing the ICE-T application, that is, before running ice- 
appnnstall. 

This step establishes a Web sender file stmcture for the IGE-T files that manage access to and delivery of dient 
applications. To establish this file stnjcture, mn the script provided in the ICE-T installation directory under /bin/ice- 
httpd-setup. 

Before you am this server setup script, you should establish links to the cgVb in directory and the hltpd^tocs direc- 
tory. 

Create a syntx)lic Bnk to the cgi-bin and htflDd-docs directories using the UNIX 1 n command. 

• Become superuser 

• Make the Onte: 



43 



EP0844 558A2 



% in ^ (absolute path to C9-b(n)/cg}-bin 
% h - s (absolute path to httpcWocs>/WVW 

If you cannot CTeate these Gnks. provide the absolute path names to cgi -bin and httpd^locs as arguments to the 
ice-htlpd-seti^ scriJL If you have not created the li^ 

erties file to specify the cgi-bin and httpd^tocs locations. (See "Customizing the Access Layer"). If you have aeated the 
linte. run ice-htlpd^etup without arguments. 

From the ICE-T installation directory, mn ice-httpd-setup.ice-httpd-setup takes these argunrtents: 

• -cqi -bin -takes the k)cation of the c-i -bin directory. 

The default is/cgi -bin. 

• -httpd-docs - takes the location of the httpd/cJocs directory. 

The default isAwww- docs. 

Note - Run ice-htttpd-setip once for each machine that is an ICE-T Web server. 

For example: 
% cd (ICE-T installation directory > 
%ybin/ice-htlpd-setup 

ice4itlpd-setup eslabfishes a Web server file structure for the f les that manage access to and delivery of requested 
client appTications. 

ice-httpd-setup perfomis these tasks: 

• Creates an ICE directory under the -cgi-bin directory 

• Creates a link to cgi -bin/ICE from the httpd-docs directory 

• Creates an applrcation startup directory under the ICE directory 

• Creates an ICEAppRepository directory 

ice-httpd-setup takes additional optkKia! a.rgjments. Run the setup file with the -help quaiWer to gel a list of the 
arguments and their defaults: 
%.cd (ICE-T installation directory) 
% A>in/ice4ittpd- settp -he^ 

Customizing the Access Layer 

This step is optiorral. The Access Layer uses authentication and access properties files to manage access to ICE- 
T applicationa Devetopers can use the ffles provided by ICE-T or modify them to specify their own access requirements 
or to CTeate a number of access subsyslenris for use with different applications. 

The Access Layer uses: 

• defaultjautJientication. oc 

defauHauthenticatkxi. cc contains a single default aulhenticatk)n function that checks the appTicalion name, 
user name, and password. By default all users are authenticated. Modify the tile to specify how to authenticate 
users. 

• default_accessj)rDperties.cc 

defaultjaccessjKOperties contains several functions for contrdfing access log tile propertes, as well as func- 
tions for specifying the Access directory, and password scrambling keys. 

With the exception of the ccpjainjocation property, (See table belwiO rra modification is necessary for these tiles, 
but you may choose to change the defaults for authentication and access properties. The fies are in the Access siixli- 

rectory in the ICE-T installation directory. 

The table appearing below describes properties that can be nrxxlified in delauft_aocessjxoperties.cc: 
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Table Default Access Properties 


5 


Property 


Default 


Description 




cgi_bin_location 


/cgi -bin 


If you have not created a link to cgi-bin (as 
described in "S^ng up the Web Server, 
provide a cgi -bin location here. 


10 


togLdestination 


logfile 


The return value detemtines where log 
entries are written. 


IS 






Accepted values: console, logfae. If you 
choose to write the k)g to a file, set the file 
k)cation and name using the bgfOe property. 




loggingjevel 


all 


Determines to what level the Access Layer 
logs access attenrpts. Accepted value: none, 
all. starts, errors, debug. 


20 
25 


logfile 

scrambler_key 


<cgi_binJocabon >/ICE/Access logs/ Access 
-jMdJog 

Uses the scrairtsler key provided by ICE-T. 


Return value is used as a k^ to unscramble 
the user name and password sent when the 
user launches an application. If you change 
the scrambler key, change the scrambler key 
in the startup applet also. 


30 


sessionErrvironment 




Sets up the calling environment for the 
server program. >bu can make calls to 
putenv ( ) to s^ environment variables 
whose values can be accessed with getenv( 
) from the server proyam. 



To implement the autl?enticate ( ) function in default„uthentication.cc: 

35 

1 copy the f fle from the ICE-T installation's Access directory. 

2. FolkTW the instructions in the file to implement the authenticate { ) function. 



40 3. In Aocess.nf^ replace this file name with yours. 

To change the defaults in defauft_access_properties.cc: 

1 . Copy the file from the ICE-T installation's Access directory and give it a name that suits the application. 

45 

2. Modify the file to supply appltcation-spedftc values. 

3. Edit Access.mk to replace the defauft fBe names with the files you edited. Accessmk is in the Access directory. 
The user-modifiable section is marked. 

so To substitute the new fOe name for defauftjauthentication.cc change the second line: 

AUTHENTICAnGNjSOURCES.cc = \ 

defauftauthentication.cc \ 

To substitute the new ffle name for defauft_access_properties.cc change the secwid line: 

ACCESS_PR0PERnES_SC)URCES.Oc = \ j 
55 defauftjttccess jxopertiesiccX 

4. Run Access.mk. 7 ~ 
% make -f Aiocesamk 
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5. After you configure the Access Layer, run ice- install -access. 

By default Access .ink aeales a an executable named CustomAccess. you have ctenged the d^auft name 
of the access program, use the - source option to ice-install-access and specify the name you have given the 
access program. For example: 
5 % ice-install-access -source myAccess 

Installing the Access Program 

The ICE-T Access Program installation script; 

TO 

• Installs the Access program on the sender in the cgi -bin directory that you specify 

• Installs the startup applets in the/www-docs/lCE/start directory. 

To install the Access program, run ice- install -access from the ICE-T installation directory: 
15 % cd (ICE-T installation directory ) 
%AMn/ice- install-access 

ice-install-access takes four optional arguments: 

• -cgi-l»n <cgi-bin kX2ttk>n> 
20 The defauA is/cgi -bin. 

• -source (Access exBcutat)le name) 

The rmme of the Access program that you are copying from. The default is Access. 

,25 ^ -dest (Access executable name) , . 

The name of the Access program that you are copying ta The default is Access. Change the destination if you 
want to use different access pro-ams for differertt applications. 

• -help 

30 Dispfays the arguments and their defaults. 

Installing the ICE-T Application 

ICE-T provides a script for Installing applicaticms. 
35 foe- app- install performs these tasks: 

• Installs the dient and server executable files for the applfoation 

• Creates an applicatfondrectory 

40 

• Installs the sender Iforaries 

• Installs the Java packages used by the Java Presentation Engine dass 

45 • Creates an applicatfon configuratfon file (appConfigRle), or installs a specified one 

If you already have an appconfigRle to whkdi you have made changes, you can avoid having the applicatfon 
installation overwrite it Use the - appConfigRle (file)optfon. 

• Copies the alDlDConf igRle to the applicatfon directory 

50 

Installing the ICE-TAppficatfon with ice-app-install 

Note -Run foe^app-install for each application you want to install 

Rom the ICE-T installation directory, mn fce-app-install with the required arguments: 

55 • -appMame-thenameoftheapplfoation 

• -peClass ~ the name of the Presentation Engine dass 
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• -peSource - the location of the Presentation Engine you want to install 

• -serverName -the name of the serv^ program 

-serverSource - the location of the server program you want to instati 

If peSource and serverSource are the same directory, you only need to specify one of them. 

ice - app- install takes additional optional arguments: ice- app- install is in the A)in directory of the ICE-T application 
installation directory. You can run the file Writh the -help option to get a list of the arguments and their defaults: 
% od <ICE-T installation directory > 
%A)in/ice- app- install -help 

Installing the ICE-T Application wHh the Pravtded Makef Qe 

An alternative to running ice- app- install, is to use the Examplamk Makef ae to install the completed w*icatk)n. 
ExamiDIa mk has defined a target for installing the appBcatton on you^ 

creating the syntx)fic nnks as descrit>ed in "Setting up the Web Server" ther you can use ExamiDle .mk with the folkw- 
ing argument 

% make -f Examplamk app-instal I 

If you did not create a symtwTic link to the cgi-t)in directory as descrtoed in "Setting up the Web Server . specify the 
cgi-bin kxatkxi in the Example.mkfile (use the CGL8iN_LOCAT!ON macro and then run make on the alDiD - install 
target 

% make -f Example.ink app-instail 
Configuring Applications 

The ICE-T appficatton installatbn script fice-app- install) generates a default application configuratk)n file (appCon- 
figRe). When a user ^arts an applicatton by launching a startup applet the Access Uyer uses the Applfcation Man- 
ager to k)ok if> values for server and client program tocattons and names in appConTigRle. Using the configuratfon file, 
the AppBcation Manager generates an HTML wrapper for presen^:ng Presentation Engines as applets in a Web browser 
execution environment (See "Using Starti^ Applets and HTML RIes" for more information dxxrt how to use startup 

applets for ICE-T applications.) 

To conplete the last step in deptoying an applwatfon to a W^ Browser you us^ 

tion-spectfic values in the HTML wrapper: 

• Run fee - app- install with the required arguments as described in "Installing the ICE-T Appficatkxi" and let it create 
the default aiDiDConfigRIa 

• Or. aeate your own applkatfon conf iguratkMi file by nrxxlifying the automatfeally generated appConf igRe. 

By default foe - app-inslall creates the applfcatfon file in the /cgi-bin/ICE/ICEAppRepository directory and names it 
(^Name ).appconf. 

To customize the appConfigRle generated by foe-app- install: 

1 . Open the generated configuratfon file ((appName).appconf) in an editor. 

2. Supply the names for each appTication in the appropriate tags in each appConfigRle. 

You are required to supply a|3plication infonnatfon in these tags: 

• (peOass)- the name of the Presentation Engine dass 

• <serverName}- the name of the server program 

• (PresentatfonEngine)- specifies where the Presentation Engine appears on the Web page. 

The Appficatton Manager replaces the (Presentatfon Engne Hag with a Java (applet > tag that specifies the 
named Presentatton Engine (peClass). 

3. Supply messages to retum to the browser if user authenticatfon or application stamp fails. 
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The template contains tags for authentication failure and appficatjon startup failure nnessages. 

The appConfigRle contains optk)nal tags for you to specify a Web page ffl^ headings, and text, just as you vwxjU 
for any Web paga 

5 The Application Manager also uses a properties f Be to set what applications are returned to the client By default, 
the Application Manager returns the application name passed to it by the Access Uyer. You can specify another appli- 
cation to return l>y modifying d^iJt_appmgr .properties. cc.defautt_appmgr jxoperties-cc is described in "Customiz- 
ing the Access Layer". 

w Presentation Engine Template 

ICE-T provides a null application that you can use as a template for Presentation En^nes. \bu can find the file for 
the tenplate in the ICE-T application installation directory under /Templates/|pe_template.iava. 

Code Example A-1 pe„templa.te.java listing 

import sutvsoft.ice.pe.*; 
^ import java. net.*; 

import java.io.*; 

import java-applet*: 
^ import java-ulil.*; 

import java-awL*; 

* This is a sample template of the ICE-T Presentation Engine - it needs to 

* be filled with the actuol ul, names of messages and handlers to create 
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* a working PE. 
V 

/ / Extend the PrescntationEngine class 

public class pe^template extends PrescntationEngine { 

// Constructor 

public pe^tempIateQ { 

/ / This is required. It sets up the internal PE components 

superO; 

) 

Code Example A-1 pe_template.java lisdng (Continued) 
/** 

* This is called when the current applet terminates. 

* It needs to be customized for handling the termination ^ - 

* of the current applet. 
V 

public void temiinate (String reason) { 
super. PEtenninate(reason); 

\ 

/** 

* This can be used to do any local initializations that may be required in 

* the PE. It is called before all the connections are setup with the server 

* so no messages should be sent from this function. 

V 

protected void initializeApplicatjonQ {} 
/•* 

' createUI creates the UI components of the applet 

* It uses the "ui" object of ''gui'' class which is generated 
^ by the SpecJava gui builder. 
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r 

* Specify the UI of the application in this function. 
V 

protected void createUIO ( 

/ / create local awt components to map the ones generated 
//by $pecJava. For example: 

} 



^ createModel Ci^te9 the data items in the ModeL Some data items 

* can be observable. These items which have an associated obsen-er 

* function that gets called when the observable is updated. 

V 

/ / This function is opricnal. It is only needed if the 

/ / application wants to do some client-side application logic 

/ / Uncomment the lines below if you plan to do client side processing 

// in the Model. 

Code Example A-1 pe.template.java listing (Continued) 
protected void createModelQ { 

/ /create the observable object e,g. PeHashtable, PeVector, PeString - 

/ / Attach observer to the observable. 

/ /put the observables into Model 
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* provide the mapping of Message names to handlers for the inbound 

* Messages to the PE from the UI or Comxn adaptors, 

* The Handlers for the UI and Model messages should 

* be provided in this function. 
V 

/ / This function is required. It keeps the mapping of UI events 
/ / registered with the uiAdaptor and the model events registered 
//with the muodcl 

protected void createMessageHandlersO throws DuplicateHandlerException { 
//Ulmaps 

uiAdaptor.addHandler fsample_ui_niessage",- 
new SampleUIHandler (uiAdaptor, uiContainer)); 
// . . . 

/ / Model Maps 

model.addHandler r5ample_modeUraes5age-, 
new SampleModeIHandler(model}); 

//.. 
) 

/* 

* main is used when running as a standalone java application* 

* (Le. not in a browser environment), and is intended to do 
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* all the things that the browser would do for the applet. 
Code Example A- 1 pe.template. Java Ustiiig (Continued) 

V 

public static void £aain(String argsQ) { 

pe^template pe = new pe.templateO; 

pe.isApplet = false; 

pe. getCommandLineArgs (args); 

pe.initQ; pe. 9tart 0; 

f 

) 

//////////////////////// UI Message Handlers 
/////////////////////////////// 

class SampleUIHandler extends PeUIHandler { 

public SampleUlHandlftr( PeUIAdaptor adaptor, PeUI uiContainer) { 

super (adaptor, xuContainer): 

) 

public boolean execute (Object caller, PeMessage message) { 

/ / decode the record send by the server 
// update the ui 
return true; 
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} 

) 

//////////////////////// Model Message Handlers 
/////////////////////////////// 

class SampleModelHandler extends PeModelHandlcr { 

public SampleModelHandler ( PfeModel model ) ( 

super (model); 

} 

public boolean execute (Object caller, PeMessage message) { 

Code ExampleA-1 pe_templatejava Listing (Continued) 

// decode the record send by the server 
/ /update the model 
return true; 

} 
) 

//////////////////////////// Model Observers 

///////////////////////////////// 
class SampleObserver extends PeObserver { 

public SampleObserver ( PeModel model) { 

super (model);. 

1 

public void update (Observable o, Object arg) { 



1 
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Startup Applet Template 



10 startAfalaJetDes^lR. Java is a Java applet that launches ICE-T applications. The file is generalized to run any ICE-T 
applicatioaVbuctonI need to charige it unless you want to change the user's irte^ TTie applet cur- 

rently asks for usemame and password arKi provides a Send button to launch (start up) the application. The file is in 
the ICE-T installation cfirectory under/StartApplet. For instructions on how to use this file, see "Using Startup Applets 
and HTML RIes". 
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Code Example B'l startAppletDevIRjava listing 

* This is a sample applet that can be used for gathering specific 

* user infbnnation before displaying the ICE*T application. It can 

* be customized as needed. It is^loaded into the browser using the 

* index-html file provided. 
V 

import java.nct-*; 
import java.io. *; 
Import Java .applet. ^; 
import java.utiL *; 
iznporc java. awt. *; 
import sunsoft. ice.ui. *; 

public class startAppletDevIR extends Applet { 

Code ExampleB-1 startAppIetDevIRjava Listing (Continued) 
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public startAppletDevIR Q { 
} 

public void init 0 { 

setLayout (new ColumnLayout 0); 
Panel £namep = new Panel 0; 

fhamep.setUyout (new FlowLayout (FlowLayout. LEFT)): 

fhaznep.add (new Label rUsemame:")); 

TcxtField &ianieText=« new Te3ttField("'»20); 

£aamep.add(£aameText); 

add(fhamep); 

Panel passwdp = new Panel Q\ 
^ passwdp.setLayout (new FlowLayout (FlowLayouLLEFT)); 
paaswdp.add(ncwLabcl("Password: *')); 
TextFieid pa88wdTejrt= new TextFieldr",20); 
pass^'dText-setEchoCharacterf/l; 
passwdp.add (passwdText); 
add(passwdp); 

Panel btnp = new Panel 0; 
btnp.setLayout (new FlowLayout Q); 
AButton cbtn = new Abutton CScnd"); 

cbtn.setAction (new sendBtn Q); 
cbtn.a4dClientData rappler^this); 
cbtn.addClieQtData f usemaine",ihameTcxt); 
cbtn.addClientData ("password" ,passwdTe3ct); 
btnp-add (cbtn); 
add(btnp); 
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show 0; 
) 

pubKc String getAppNamcO { 
appnazne = getParameter (-AppNamc'): 
returo appname; 
} 

public String getAccessName Q { 
String acc =* getParameter f Access"); 

Code ExampleB-l startAppletDcvIRjava Listing (Continued) 

if (acc == ntiU 1 1 acc,equals('"') 1 acc-" Access": 

return acc; 

) 

public String gptAppHost 0 { 
System-err.printin ("Applet: ''+isApplet); 
if (isApplet) ( 

URL docBase=getDocumentBase Q; 
Systcm.crr.priritlnrDocument base: ''+docBai5eJ; 

apphost=docBase.gexHo$t Q; 

if (apphost==null) apphosc='"'; 

int port=docBa$e.getPort Q; 

if (port -1) apphost = apphost + "r^+port; 

System, err.printlnrServer is: f^apphost^^"*}"): 

I else { 

aCThost*"-; 
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\ 

return apphost; 
1 

public static void main (String agrs(]) { 
Frajne f = new Frame f ICE-T starcu'p applet"); 

startAppletDevIR tap =- new startAppletDevIR 0; 

tap.isApplet=^se; 

t^.init 0; f add TCenter'. tap); 

f.resize (500.400); 

f.show 0; 

tap.startO: 

I 

public boolean i^pplet=true; 

private String appname = new Stringf); 

private String apphost = new Stringf"); 

} 

/* 

* sendBtn handles the ""Send" button activation. The execute 

* member of this class is called when the "Send" button is 

* pressed. It collects all the relevant user information and 

Code BxampleB-1 staitAppIetDevUtjava Listing (Continued) 

* sends it to the Server via HTTP. This is done by executing 

* the Access function in the server's cgi-bin, 

* [Note: the usemame and password is scrambled so it will not 

* be displayed in the URL field of the browser.) 
V 
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class sendBtn extends Activity { 

public boolean execute {Object caller, Event event) | 

AButton btn= (AButton) caller, 

startAppletDevIR app = (startAppletDevIR) {btn.getClientData Tapplet")); 

TextPield name = CTextPield) {btn.getClientData 

("uscmamc")); 

TextPield passwd = (TextField) (btn.getClientData 
f password")); 

String servemame ^ app.getAppHost Q; 

URL newURL - null; 

String usemaine=Tiame.getText 0; 

String userpasswd=p^2*^-S^*^^ 0- 

String appname = app.getAppNamc Q; 

String accessName-app.getAccessName Q; 

AccessScrambler scrambler=new AccessScrambler 0; 

System.err.println fScrambling f +usemaine+% 

/ / useTpasswd+" , "+ 

appname^*')"); 

String 5crainbled=scrambler.scrainbleUser (usemame, userpasswd, appname); 
System-err.printlnf scrambled ==> [•+5crambled+-]-); 

String url="http: //- + servemame + 
•'/cgi-bin/''+acccssNamc + + appname + 
+ scrambled: 

System.err.println (url); 

try{ 

newURL = new URL(m:l); 
} 

catch (Exceptdon e) { 
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System.err.println fException Getting ncwURL from r*^ri+''): 
) 

AppleiContext cont = app-getAppletContextQ: 
if {cont l" null) { 

Code ExampleB-1 startAppletDevIRjava Listing (Continued) 
/* 

* The call to ShowDocument makes the httpd request to the Access 

* cgi-bin executable. 
• 

* Call ShowDocument with one ajrgument (the URL) to show.the 

* PE in a single window; call with two arguments (the URL, •newjwindow") 

* to show the PE in a new browser window. 

* We're currently defaulting the call to bring up a new browser 

* window because of the way browsers handle backing cut of html 

* pages with java applets — if you go too fiar back, then the applet 

* is destroyed. We put the PE in a new window to minizni^e the chance 

* of going too far back simply because you want your browser back. 

* but don't intend to kill your PE. 
* 

V 

System, err.println TShowing document in new window: f +newURL+''l in 
window: {-+appname+*')"); 
cont.showDocument (newURL, appname); 
//cont ShowDocument (newURL); 

//Sy3tcm.err.println ("Showing document: [*'+newURLV'l-); 

return true; 
) 
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5 

Server Program Templates 

This appencfix contains code listings for the following templates: 

10 

sefver_template.c 
• defautt.main.c 
75 • server_template.cc 
defautt_main.cc 

Chapter 2. **Building Program Components descrfoes the location and u& i of these templates. See "Handling Mes- 
20 sages in the S^er Program** and "Modifying the Default main Routine (Optional)** for more information. 

Gh- Files 

ICE-T provides a server program terrplate arxJ a detault main routine for application developers using C++ to 
25 develop server programs. . -^ ., .^ -^ 

&H- Server Pro-am Template 

Code Example C-1 3eiver_teinplate.cc Listing 

30 - 

* seiver_tcniplate.cc 

35 

* 

* This is a template of a ICE-T seiver-applicatioii in C+* 
V 

40 
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#include <3tjdio.h> 
#include <string.h> 
#include <9ys/typcs.h> 

/ / these arc required to get the server side ICE-T components 

#include "SrvData.hh" 
#include "SrvComm.h" 
#include "SrvMessage.hh" 

#define false 0 
#define true 1 

* The Message Handler functions * 

/* This is ;he Message handler function that gets called when a specified 

* znes.<^e is received from the client. It has oiily one argument 

* (msg) that contains the message name and message data. 
V 

void handleMessage (SrvMeasage *msg) { 

r 

^ disassemble incoming data 
V 

Code Example C-1 server_templatc.cc Listing IConnnued) 
/* 

SrvData *data; 

data°message->getData£lement (0); 
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V 

/* 

■ The application "Logic'' */ 
V 

/* 

* Assemble outgoing data 

V 

/ / send a reply if neces&aiy . <rcplyData> can be of the types 
/ / provided in SrvData.hh 

SrvMessage *reply^ew SrvMessage f replyMessageName"); 
repIy->adclDataEleinent (<replyMessageData>); 
SrvComm_sendMessage (reply); 
V 

r 

} 

I /This is an example of a shutdown handler on the server 

void shutdownHandler (SrvMessage *shutdownMsg) { 

char *shutdownType= ((SnrString *) shutdownMsg->getDataElement (0)) - 

>getValue Q; 

char *reasonString= ((SrvString *J shutdownMsg->getDataElement {l))->getValue 

0; 

if (Istrcmp (shutdownType/ICET.CLIENT-SHUTDOWN")) { 

fprintf (stderr/shutdownHandler: Detected CLIENT SHUTDOWN event. 

Reason=%8\n\ reasonStrin^; 

} else if (Istrcmp (shutdownType;iCET_CUENT_DISCONNECr)) ( 



62 



EP0844 558A2 



fprintf (stden-.^shutdownHandler: Detected CLIENT DISCONNECT event 
Rcason=%$\n'*, reasonStrixig); 

\ else if (!strcnip(shutdownType/ICET_SERVER,SHUTDOWN-)) { 
fprintf (stderr/shutdownHandler: Detected SERVER SHUTDOWN event 
Reason~%s\n", reasonString); 

} else if (!strcmp (shutdownType/ICETjNTERNAL_SHUTDOWN")) { 

Code Example C- 1 server_templatexc Listing (Continued) 

fjprintf (stderr/shutdownHandler: Detected INTERNAL SHUTDOWN event. 
Rea5on=%s\n\ reasonString): 
) else { 

fiprintf (stderr/ Shutdown Handler: unknown msg type (%s). Reason=%8\n". 

shutdownType, reasonString); 

) 

\ 

* 

* Functions required by default-main, that set the 

* SrvComm library properties {setSrvC^mmProperties) and 

* initialize the appIicationService (InitializeApplicationSeivice) 
* 

int setSrvCommProperties 0 { 

/* The server timeout is how long the server waits between receiving 

* messages from the PE before it initiates the timeout shutdown procedure, 
V 

SrvCoram^sctServciTimeout (300); /* in seconds */ 

The accept timeout is how loiig the server will wait to accept a connection 

* from the client before it shuts down. 
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V 

SrVComiii_sctAcceptTiineout (400); /* in seconds */ 

return 1; 
) 

int creatcMessageHatndlers () ( 

SrwComm^addMcssagcHandler rSamplelncomingMessagc", handleMessage); 
SivComnuaddMcssageHandler ("ICCT^SHUTDOWN", shutdownHandlcr); 

return 1 ; / / (return 0; if there is a problem here) 
} 

int initializeAppIication Q { 

retum 1; // (return 0; if there is a problem initializing the application) 
I 

Defautt main for C4-4- 

Code Example C-2 default.main.cc Listing 

* de£s^ult_main.cc 

* This file implements the default main () used 

* by an ICE-T server executable. 

* The structure of this main is that it calls 

* all the Auctions necessary to run 

* the ICE'T SrvCom hl>raiy, and provides several 

* places for the application writer to include 
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* application-specific code. These functions 

* are implemented by the application-writer, 

' and arc usually implemented in a separate file, that gets 

* linked in as part of the build process. 
* 

* These functions all return int values, which are used to determine if 

* ihc startup of the application should continue or should be aborted. 

* In this tvay the application code has a hook for indicating when something 

* goes wrong (can't connect to database, or something)* and passing this 

* information on to the application so startup doesn't continue. 

* Return 1 (TRUE) to indicate that everything is OK. or return 0 (FALSE) 

" to indicate a fatal problem that should result in aborting the application 

startup, 
ft 

* int setSrvComProperties Q 

* Fill in this function to set properties on the SrvComm library. 

* This fimction is called after the SivCom library is created, but before it accepts 
^' a connection from the dicnt. 

* int createMessagHandlers () 

* Pill in this function to register the message handlers. 

* This function is called imediately after setSrvCommProperties Q. 
* 

* int initializeAppUcation Q 

* Fill in this function to start up the application-specific code. 

* It is called after the coimcction is accepted from the client, 

* and before the message reader and handler loops are started. 
* 

* Code Example C-2 default_main.cc Listing (Continued) 

* NOTES: j 

* This main 0 routine is provided for your convenience. 
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* but you arc not required to use it You arc 

* free to write yotir own main 0 routine, provided 

* you foUow the requirements for ordering the 

* caUs to the SrvComm library: 

* 1. First call create-SrvCommCtcp"); to create 

* the Comm library's data stnicturca. 

* 2. Set the properties on the Comm library and 

* register message handlers and other handlers* 

* 3. Call SrvComm_creai»Socket Q to create the 

* listener socket and output the port number 

^ (Note: do NOT write anything to stdout before 

* making this caU). 

* 4. Initialize the application. 

* 5. CaU SivComm^acceptClientConnection 0 to 

* accept the connectio fromthe dicnt. 

* (Note: sreps 4 and 5 may be interchanged) 

* 6, FinaUy SxvCoinm_atart Q to start the 

^ Comm library 3 loops. This routine does not 

* return until everything is finished. 
* 

#include <3tdio.h> 
#include <stdk^.h> 
#include <string.h> 
#include <sysytype3.h> 

#include •SrvComm.h" 

extern int setSrvCommProperties Q; 
extern int createMessageHandlers 0; 
extern int imtializeAppUcation 0» 
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The default Main 

■* 

♦ ICE-T provides a default mainO routine 

* for ICE-T server applications. 

Code Example 02 defaultjnaiii.cc listing (Continued) 

int 

inain( 

intargc, 

char**argv» 

char**cnvp 

) 
{ 

char *protocol=''tcp-; 
create_SrvCoinin(protocol); 

* Call user-defined function to set the properties on the Comm Libraiy. 

* Then call user-defined function to create the Message handlers 

* and add them to the Comm library. 
* 

* The setSrvCommProperties function is where Comm Library properties 

* are set All properties have reasonable defaults, so none of them are 

* required to be set. 
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* The createMcssagcHandlers function is where the message handlers are 

* added, and other handlers (shutdown handler, default message handler, 

* etc) are registered. 

* Requirements on these rwo functions: 

* 1. These functions may NOT write anything to stdout, since the Access 

* layer expects the first thing on stdout to be the port number that 

* the server will be listening for a client connection on. 

if (la etSrvCommProperxies 0 ) | 

exit (0); 

\ 

if (IcreateMessageHandlers 0 ) ( 

exit(0); 

} 

r 

* Create the socket that the client wiU connect to. 

* This XDUtine also is responsible for generating (and printing to 

Code Example C-2 defaultL.main.cc Listing (Continued) 

* scdout) the port number so the Access layer can generate the 

* html code that passes the port number to the client applet 

* (presentation engine). 
• 

* (NOTE: Do not write anything to stdout before this routine is called. 

* Writing to stderr is OK, however.) 
V 
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if (SrvCoimn_crcateSocket 0 N SRVCOMKLSTATUS-OK) { 

exit(0); 

} 

fprintf (stderr.'ICE: ApplicationSeiver. port=%d 
ServerIP=%s\n".SivCoinin_getPort 0. SfvComni_getIPAddresa 01; 
fprintf {stderr,'\ii\n\ii\n"); 
£aush(stderr]; 

/* 

* caJl user-defined function to initialize the application 
« 

* Requirements on this funetion: 

* 1. This fvinction initializes any data structures in the application 

* that need to be initialized before messages incoming messages 

* from the client get handled. 

* 2. This fiinction must return, this means that if the application has 

* its own notifier loop that. say. listens to messages from a database, 

* then that notifier loop must be called in a new thread. 
V 

if (iinitializeApplication 0) i 
exit(0): 

\ 

r 

* Accept a connection from the client. 

* (blocks until a connect attempt is made, or until the 

* acceptTimeout expires). 
•/ 

if |SrvComm_acceptCUentConnection 0 != SRVCOMM_STATUS_OK) { 

exit(0); 

) 
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r 

* Finally, we start up the server loops. 

* This iunctioa docs not return until everything is finished. 

Code Example C-2 defa\ilt_niain. ce Listing (Continued) 
V 

SrvCoinm_start Q; 
\ 

r 

^ This function is called when the server times out. 

* It returns TRUE or FALSE (int 1 or 0), TRUE indicating that the 

* timeout-shutdown should proceed; FALSE indicating that no. don't 

* shutdo\vn on this timeout (the timeout dmfir gets reset). 

V 

*/ #ifdef _cplusplus 
extern "C^i 
#endif 

int handleServerTimeout Q ( 

return 1; 

} 

#ifdef _cphisplus 
} 

#endif 
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C Server Program Template 

Code Example C-3 sciver-tcmp late, c Listing 

♦server-template, c 
« 

*ICE-T server template. 

V 

#include <stdio.h> 

#incmde <string.h> 

#iidude <sys/types-h> 

#include 'SrvData-h" 
#jijclude "SrvComm-h" 
ttinclude "SrvMesaagch" 
^define false 0 
#dttfine true 1 

/*This is the Message handler function that gets called when a specified * 
message is received from the cUent. It has only one argument * (msg) that 
contains the message name and message data. 

V 

void handleMessage(SrvMessage *message) { 

r 

^disassemble incoming data 

V 

/* 

SrvData *data; daia=SrvMessagc-gctDataElement (message, 0); 

V 

CodeExample C-3 server-template.c Listing (Continued) 
* The application "Logic" ,/ 
Assemble outgoing data ,/ 
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— see SrvDaia-h for how to create data types. -SrvData ,replyData; replyData= 
create-SivVectorfl; 

SrvVector-addElementCreplyData, create-SivStringrSomethin^)); ,/ 
/ 

Create the SrvMessage struct ,/ 
/rcply=create-SrvMessage{"replyMessage"); 
SrvMcssage-addDataElemLent(replyData); ,/ 

•Send message ./ 

/*SrvComin-sendMes3age(repty); ,/ 

/*This is an example of a shutdown handler on the server */ 
void shutdownHandler(SrvMessage ,shutdownMsg) { 

SrvData »shuldownTypeSStr= SrvMessage-getDataElemeht(shutd6wnMsg. 0); 
SnrData *reasonSStr= SrvMessage-getDataElement(5hutdowiiMsg,l); char 
*rea5onString=SrvString-getVahie(reasonSStr) ; 
Code Example C-3 server-template, c Listing (Continued) 
char *shutdownType=SrvString'getValue(shutdownTypeSStr); 
if (/strcmptshutdovmType/ICET-CLIENT-SHUTDOWN^ { 
fprintf(stderr/shutdownHandIer: Detected CLIENT SHUTDOWN cvenf- 
Reason=%s\n'', reasonStnng); 

) else if {:strcmp{shutdownType/lCET-CLIENT-DlSCONNECr)) { 
fpiintflstderr/shutdownHandler: Detected CLIENT DISCONNECT event, 
Rea5on=%3\n'', reasonString): 

) else if (!strcmp(shutdownType/ICET-SERVER-SHUTDOWN-)) { 
^rintf(stderr/ahutdownHandler: Detected SERVER SHUTDOWN event 
Reason-yosXn", reasonString); 

} else if (:strcmp(shutdownType,-ICET-INTERNAL-SHUTDOWN^)) { 
^rintHstderr/shutdownHandler: Detected INTERNAL SHUTDOWN event. 
Reason=%s\n", reasonString; 
I else { 

fprintf(stdeiT,*'Shutdown Handler: unknown msg type (%s). Reason=%s\n", 
shutdowniype^ reasonString); 
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) 
) 

* Functions reqiiircd by default-main, that set the 

* SrvCornm library properties (setSivCommProperties) and 

* initialize the applicationScrvicc (initializeApplicationSerwice) 

**-rt************************************ *****'*****'**** 
int setSrvCommPropertiesO { 

/*The server timeout is how long the servci* waits between receiving 
^messages from the PE before it initiates the timeout shutdown procedure. 
*/SivComin-setServeiTimeout(300);//in seconds */ 

/*The accept timeout is how long the server wiU wait to accept a coimection * 

from the client before it shuts down. 

*/SrvComm-setAcceptrimeout(400); /* in seconds */ 

return 1; 

} 

int creatcMessageHandlersQ 

{ STvCoTnm-addMessageHandler("SampleIncomingMesssage\ handleMessage); 
STvComm-addMessageHandlerTICErr-SHUTDOWN". shutdownHandlcr); 
return 1; 
) 

int initializeApplicationO { 

return 1; 

) 
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Default mainfbrC 

Code Example C-4 default-iiLaiii.c Listing 
****»*^****^**^***'*'*******^**** ****** 

detaialt-mainx 

This file implements the default mainQ used by an ICE-T server executable. 
The structure of this main is that it calls 
all the required fianctions necessary to run 

the ICE-T SrvComm library, and provides several places for the application 
writer to include application-specific code. These functions are required to be 
implemented by the application-writer, and are usually implemented In a 
separate file, that gets linked in as part of the build process. 

These functions all return int values, which are used to determine if the startup 
of the application should continue or should be aborted. 

In this way the application code has a hook for indicating when something goes 
wrong (can't connect to database, or something) , and passing this information 
on to the appiii::ation so startup doesn't continue. 

Return 1 (TRUE) to indicate that everything is OK, or return 0 (FALSE) 

to indicate a fatal problem that should result in aborting the application startup. 

int setSrvCommPropertiesO 

Fill in this function to set properties on the SrvComm library. This function is 
called after the SrvComm library is created, but before it accepts a connection 
from the client. 

int createMessageHandlersO 
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10 



15 



Fm in this function to register the message handlers. 
This function is called immediately after setSrvCommPropeitiesO. 
int initializeApplication{) 

Fill in this function to start up the application-specific code. It is caUed after the 
connection is accepted from the cUent, and before the message reader and 
handler loops axe started. 

NOTES: 

This mainO routine is provided for your convenience, 
CodeExample C-4 default-main. c Listing (Continued) 

but you are not required to use it. You are free to writc.your own mainO routine, 
provided you follow the requirements for ordering the calls to the SryComm 
library: 

^ 1. First call create-SrvCommf tcp"); to create the Comm libraxy's data 
structures- 



20 
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2. Set the properties on the Comm library and register message handlers 
and other handlers. 

3. CaU SrvComm-creatcSocketO to create the listener socket and output the 
port number (Note: do NOT write anything to stdout before * making this call). 

4. Initialize the application. 

5. Call SrvComm-acceptClientConnectionO to accept the coimection fromthe 
client (Note: steps 4 and 5 may be interchanged) 

6. Finally call SrvComm-startQ to start the Comm library's loops. This 
routine does not return until eveiything is finished. 
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#mclude <stdio.h> 

#include <3tdlib.h> 

#mclude <string.h> 

#include <8ys/types.h> 

#mclude "STvCoinm.h" 

extern int sctSrvCommProperdesQ; 
exiem int createMessageHandlersQ* 
extern int initi2dizeApplicationO; 

* The default Main 

* ICE-T provides a defkiilt mainQ routine 

* for ICE-T server applications. 

int 

main( 

intargc, 

char**argv, 

char**envp 

) 
{ 



char ,protocol=*'tcp": 
create-SrvComm(protocol): 
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•Call user-defined function to set the properties on the Comm Library. * Then 
call user-defined function to create the Message handlers * and add them to the 
Comm libraiy. 

The sctSrvCommProperties function is where Comm Library properties are set. 
All properties have reasonable defaults, so none of them are required to be set. 

The createMessagcHandlers function is where the message hamdlers are added, 
and other handlers (shutdown handler, defaialt message handler, etc) arc 
registered. 

•Requirements on these two functions: 

*1. These functions may NOT write anything to stdout, since the Access , 
layer expects the first thing on stdout to be the port number that * 
the server will be listening for a client connection on. 

^/if (rsetSrvCcmmPropcrticsO ) { 
exit(0): 

\ 

if (IcreateMessageHandlersQ ) { 

exit(0); 

I 

/* 



* Create the socket that the c&ent will coxmect to. 
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*This routine also is responsible for generating (and printing to 
*stdout| the port number so the Access layer can generate the 
*html code that passes the port number to the client applet 

CodeExample C-4 default-mnin.c LLstmg (Continued) 

•(presentation engine). 

'(NOTE: Do not write anything to stdout before this routine is called. 
*Writing to stdcrr is OK, however.) 

V 

if (SrvComm-createSocketO SRVCOMM-STATUS-OK) { 
e)dt(0); 

fiprint£(stderr/ICE::ApplicationServen port=%d 
ServeriP=%s\n",SrvCoram-getPortO, SrvComm-geUPAddressO); 
fprintf[3tderr/ \n\n\n\n"); 
fnush(stderr); 

/* 

* call user-defined function to initialize the application 

^Requirements on this function: 

* 1. This function initializes any data structures in the application 

* that need to be initialized before messages inconung messages 

* from the dient get handled. 



Ik--." 
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This function must return. This means that if the application has 
its oom notifier loop that, say. listens to messages from a 
database, then that notifier loop must be called in a new thread. 



V 



if (!initiali?eApplicationO) { 
exit (O); 



♦Accept a connection from the client, . , - - 
♦(blocks until a connect attempt is made, or until the 
*acceptTimeout expires). 

Vif (SrvComm-acceptCUentConnectionO 1= SRVCOMM-STATUS-OK) { 
e>dt(0); 

/* 

^Finally, we start up the server loops. 

*Thi8 function does not return until everything is finished. 

SrvComm-startO; 

This function is called when the server times out. 
It returns TRUE or FALSE {int 1 or 0), TRUE indicating that the 
timeout-shutdown should proceed, FALSE indicating that no. don't 
shutdown on this timeout (the timeout timer gets reset). 

V 

#ifdef — cplusplus 
extern X- 
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#endif 

int handleSeivcrTimcoutO { 
return 1; 

} 

#ifdef —cplusplas } 
#endif 



ICE-T Exceptions Catalog D 

ICE-T client program exceptkxis are caught tjy the modules in the Presentation Engine. The IcelExcelDtionHancDer 
generates exception messages. It issues warnings and errors t>y printing messages to the Java console in a Netscape 
Navigata envfrona^ent. or to the teiTnlna! where Java was started (in the case of the Java development kit). 

Server (Communication Library excqstions are caught by the modules in the Communication Layer. The s 
erverExc ep t i onHandler generates messages. It issues warnings and errors bf printing nrtessages to the application 
logfile if the application is launched i:.rx\ a browser or to stdout if the application is run standAlona 

Here is a sample^ message: 
ICET WARNING: tandled in PresentationEnglneJnit 
Attempt to reglst^ duplicate handiers. 

Figure 30 is a table of client and server side exceptions in accordance with a preferred embodiment 

While the invention is descrft)ed in terms of prefen-ed embocfiments in a spedTic system environment, those skilled 
in the art will recognize that the invcrrtion can t>e practk;ed. with modification, in other and different hardware and soft- 
ware environments within the spirit and scope of the appended claims. 

aaims 

1 . A server for a distributed system, comprising: 

(a) a client computer; 

(b) a server computer; 

(c) a networii connecting the client computer to the server computer; 

(d) an execution framewortc code segment conftgured to couple the server computer and the dient computer 
via the networt^ comprising: 

(1 ) a plurality of client computer code segments resident on the server, each for transnvsston over the net- 
work to a client computer to initiate coupling; 

(2) a plurality of server computer code segments resident on the s^ver which execute on the server in 
response to initiation of coupling via the networic with a particular dient utilizing the transmitted dient com- 
puter code segment for comnunicating via a particular communication protocol; 

(e) the dient computer code segment including a mediator state machine which receives a plurality of mes- 
sages, determines which message should be handled t>y which part of the execution framework, and fonwards 
the message for further processtng.to the execution framework; arxl 

(e) the execution framewortc dispatches messages and iretiates events in response to characteristics of the 
message transferred by the meCGator state noachine. 

2- The sen^ lor a distnlxJted system as redted in daim 1 , induding a user interface part off the dient code segment 
which receives messages containing user interface information arxl translates the user interface information into 
display information. 
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3. The server for a distrtxjted system as redted in daim 1, inducting a convnunication adaptor for communicating 
message types txxind for external consumption to the network. 

4. The senrer for a distributed system as redted in daim 1 . induding a web connection which tadlitates communica- 
tion from the dient computer to ttie server computer. 

5. The server for a distrtouted system as redted in daim 1 , induding a communication protocol corresponding to the 
dient code segment and the server code segment wtiich is supported by a communication library on the dient com- 
puter arxi the server computer. 

6. The server for a distributed system as redted in daim 1 . induding a code segment which authenticates an initial 
request from a dient conputer before downloading a dient code segment and initiating secure convnunication. 

7. The sender for a distrflxrted system as redted in daim 4. wherein the web is the internet 

a A method for distrtoutingcorrputing between a sender conrputer system a^ 
a networK comprising the steps of: 

(a) coupfing the sender conputer and the dient computer through the network utilizing an execution fr-c imework 
code segment, comprising: 

(1) a plurality of dient conputer code segments resident on the server, each for transnussion over the net- 
work to a dient computer to initiate coupling; 

(2) a plurality of server conputer code segments resident on the server which execute on the sprver in 
response to initiation of coipling via the network with a particular dient utilizing ttie transmitted client com- 
puter code segment for communicating via a particular communication protocol; 

(b) receiving a plurality of messages at the dient corrputer code segment induding a mediator state machine; 

(c) deternwning which message should be handed by which part of the execution framework at the mediator 
state macNng; 

(d) forwarding the message for further processing to the execution framework; and 

(e) cfispatching messages and initiating events in response to characteristics of tiie message fransferred by the 
mediator state machine 

3. The method as redted in daim 8, induding the step of invoking a user interface part of the dient code segment to 
receive messages containing user interface information and franslating the user interface infonnation into dsplay 
informatioa 

10. The m^hod as redted in daim 8, induding the step of communicating message types bound for external consump- 
tion to the network utilizing a commuiication adaptor. 

1 1 . The method as redted in daim 8. induding tiie step of utilizing a web connection whk:h facilitates communication 
from the dient computer to the senrer computer. 

12. The method as redted in daim 8. induding the step of utilizing a communkation protocol corresponding to the di- 
ent code segment and the server code segment which is supported by a communication library on the dient com- 
puter and the server computer. 

13. The method as redted in daim 8, induding the step of authenticating an initial request from a dient computer 
before downloading a dient code segment and initiating secure communication. 

14- The method as redted in daim 11, wherein the web is the Internet 

15. A conputer program embodied on a conputer-readable medium Ux enabling a distributed conputer system, com- 
prising: 

(a) a code segment fcx responding to a request from a dient computer system to a server computer sy^em; 
and 
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(b) an execution framework code segnnent configured to couple the server computer and the client conputer 
via the network comprismg: 

(1 ) a plurality of client conputer code segments resident on the server, each for transmission over the net- 
5 work to a dient computer to initiate cou^^ing; 

(2) a plurality of server confYXJter code segments resident on the server which execute on the server in 
response to initiation of coupling via the network with a particular dient utilizing the transmitted dient com- 
puter code segment for comnrunicating via a particular communication protocol: 

10 (c) the dient computer code segment induding a mediator state machine which receives a plurality of mes- 

sages, detem^nes which message should be handled t3y which part of the execution frameworK and forwards 
the HDessage for further processing to the execution framework; and 

(d) the execution framework induding code that dispatches messages and initiates events in response to char- 
acteristics of the message transferred by the mecfiator state machine. 

15 

16. The computer program enrtodied on a computer-readable medium for enabling a distn*buted computer system as 
redted in daim 15. induding a user interface part of the dient code se^ent whk:h receives messages containing 
user interlace information and translates the user interface informatxsn into display information. 

20 17. The computer program embodied on a computer-readable medium for enabling a distributed computer system as 
recited in claim 15, induding a commur^cation adaptor for convnunicating message types bound for external con- 
surrption to the network. 

18. The computer program embodied on a computer-readable medium for ^at)ling a d'^txjted computer system as 
25 recited in daim 15. iriduding a web connection which fadlita^es comnminication from the dient computer to the 

server conrputer. 

19. The computer program embodied on a computer-readable medium for enat)ling a distributed computer system as 
recited in daim 15. induding a communication protocol corresponding to the client code segment and the server 

30 code segment which is supported by a communication Ibrary on the dient conrputer and the server corrputer. 

20. The computer program embodied on a computer-readable medium for enabling a distributed computer system as 
recited in daim 1 5. induding a code segment which authentk;ates on initial request from a dient computer before 
downloading a dient code segment and initiating secure communication. 

35 

21. The computer program embodied on a computer-readable medium for enabling a distributed computer system as 
redted in daim 18. wherein the web is an Internet. 
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BASIC BUILDING BLOCKS: PE OBJECT 
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• ADDCHILD 
OO • GETCHILD 



1900 



DATA STRUCTURE LIBRARY 
USED FOR BUILDING THE 
MODEL AND OTHER 
STRUCTURED DATA PASSED 
AROUND. 

CONTAINMENT HIERARCHY: 

• PRIMITIVE 

• COMPOSITE 

• OBSERVABLE C'ACTIVE 
OBJECTS") 

• POLYMORPHIC. SELF- 
DESCRIBING 

• SERIALIZATION INTERFACE 

^1920 
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BASIC BUILDING BLOCKS 



2000 



PE EVENT 
HANDLER 





O 



^HANDLER tkl HANDLER 



PE EVENT HANDLER 
• PEINFO 
•RECEIVECB 



p-iMSG 



USED BY VIEWS TO HANDLE 
INCOMING MESSAGES AND 
Ul EVENTS. 
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• DISPATCH BASED ON NAME 
FIELD 

•PEINFO CONTAINS DATA 
PASSED TO RECEIVECB 

•RECEIVECB IMPLEMENTS 
MAP TO MODEL 
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BASIC BUILDING BLOCKS: PE INFO 



O 



O 



PE INFO 

• STRING NAME 

• PEOBJECT DATA 



-2100 

BASIC UNIT OF DATA MOVED 
BETWEEN 

FUNCTIONAL COMPONENTS. 



• ENCAPSULATE EVENT AND 
MESSAGE SIGNATURES 

• USED IN 3 PLACES- 
PASSED BETWEEN: 

MODEL AND XIF VIEV^ 
MODEL AND MSG VIEW. 
XIF VIEW AND Ul 



FIG.'21 



CLIENT 



BROWSER 



APPLICATION 
URL 




STARTUP 
APPLET 



SERVER 



SERVER U 
PROGRAM 



[access y 



WEB 

server 



DB 
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2270 







PEINFO 
CALLBACK 


EXT. IF/ 

VltW / 

DISPATCH 


lol 



MEDIATOR 



Ul 
EVENT 



2292-/ 



UI->MODEL MAP 
(RECEIVECB) 




2290 



MESSAGE 
K VIEW 

UNPACK 
DISPATCH 



3^ 



COMM. 
LAYER 




SET 
VALUE 

GET 
VALUE 



MESSAGE 
(BYTESTREAM) 

\-2200 



2250 

FIG. 22 
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MAG 
HANDLER 



ol PEINFO 



2210 



2220 



MAG->MODEL MAP 
(MSGRECEIVECB) 

2230 



2360 





~X ' 

-2370 ][ 


PEINFO 

Al 

CALLBACK 


EXT. IF/ 

view/ 
dispatch 


Vt-2382 
loi 



MEDIATOR^ 



T 



2302 

t 

2380 
2310 



MESSAGE 
^ VIEW 

UNPACK 
DISPATCH 




COMM. 
LAYER 



MESSAGE 
(BYTESTREAM) 



2300 



Ul^ i 

EVENT 2384 -A 

UI->MODEL MAP 
(RECEIVECB) 



2342 




SET 
VALUE 

GET 
VALUE 



2340 




2320 



O PEINFO 



MAG->MODEL MAP 
(MSGRECEIVECB) 

2330 
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2480 




MEDIATOR 





MESSAGE 




VIEW 




0^ 



LATE 2460 
Ui 

UES BUILD 
V2490 





MESSAGE 
(BYTESTREAM) 

. V 



2400 



2460 



SENDMSG 
2430 



2450 -J^l 

FIG.-24 SET SET 

OBSERVER OBSERVER 



BUILD 
PEINFO 



2440 



2590 




MEDIATOR 



^EXT. IF 




MESSAGE 


VIEW 




VIEW 






0^ 



/ 



l-TP SEND 
UIEVENT 

UES 2560 -A^ 

^2592 BUILD 
PEINFO 

2550 



COMM. 
LAYER 




MESSAGE 
(BYTESTREAM) 

V: 



2500 



2510 



SENDMSG 
2530 



BUILD 
PEINFO 



2540 



r>T^ SET SET 

FIG*'25 OBSERVER OBSERVER 
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RUNTIME 1 


IS USED BY YOUR 
INSTANCE OF THE 
PRESENTATION ENGINE. 




A COMPILED 
PRESENTATION ENGINE 
(HERE NAMED MY 
PRESENTATION ENGINE) 
THAT INCLUDES A GUI AND 
AN INSTANCE OF THE 
CLIENT COMMUNICATION 
LIBRARY. 


DEVELOPLMENT 


IS DERIVES FROM. 
IS NOT MODIFIED. 
IS MODIFIED. 


DEVELOPERS COPY THIS 
FILE, GIVE IT A NAME. AND 
WRitE METHOD BODIES 
FOR A FEW Mb I HODS 


IS DEVELOPED FROM THE 
PE-TEMPLATE. 








o 


DESCRIPTION 


IS THE SUPERCLASS 
FOR PRESENTATION 
ENGINES. 


IS AN INSTANCE OF THE 
PRESENTATION ENGINE 
CLASS. 


IS AN INSTANCE OF THE 
PRESENTATION ENGINE 
CLASS, CREAIbD USING 
PE-TEMPLATE AND FILLE 
IN WITH APPLICATION- 
SPECIFIC CODE. 


NAME 


PRESENTATION 
ENGINE CLASS 


PE-TEMPLATE 


MY PRESENTATION 
ENGINE 

(A DEVELOPED AND 
COMPILED 
PRESENTATION 
ENGINE. GIVE AN 
EXAMPLE HERE) 



97 



EP 0 844 558 A2 



FUNCTION 


DESCRIPTION 


REQUIREMENTS 


SET SERVER 
COMMUNICATION 
PROPERTIES 0 


SETS SERVER 
UUMMUNIUAI lUN 
LIBRARY 

PROPERTIES SUCH 
AS SERVER 
TIMEOUTS. AND 
DEBUG FILE AND 
TRACE LEVEL 


SHOULD NOT WRITE 
ANYTHING TO STDOUT 
BECAUSE THE ICE-T 
ACCESS LAYER 
EXPECTS THE FIRST 
THING WRITTEN TO 
STDOUT TO BE THE 
PORT NUMBER THAT 
THE SERVER USES TO 
LISTEN FOR THE 
CLIENT CONNECTION 


CREATE MESSAGE 
HANDLERSO 


REGISTERS THE 
MSSG HANDLERS. IS 
THE SRVR ANALOG 
TO THE CREATE 
MSSG HANDLERSO 
METHOD IN THE 
PRESENTATION 
ENGINE. 


CALLED IMMEDIATELY 
AFTER THE SET 

SERVER 

COMMUNICATION 
PROPERTIES 0 CALL 


FIG.'28 


PROPERTY 


DEFAULT ACCEPTED VALUES 




SET SERVER TIMEOUTQ 


3600 SECONDS 
(1 HOUR) 


>0 

SPECIFYING 0 OR <0 
MEANS NO TIMEOUT 


SET DGB FILE 


STDERR 


USER-SPECIFIED 
FILENAME 


SET ACCEPT TIMEOUT 


3600 SECONDS 


>0 

SPECIFYING 0 OR <0 
MEANS NO TIMEOUT 


SET TRACE LEVEL 


0 (ZERO) 


0 MEANS NO TRACE 
MESSAGES ARE 
PRINTED. 2 MEANS 
TRACE MESSAGES 
ARE PRINTED. 


SET THREAD MODEL 


SERVICE 

COMMUNICATION- 

THREAD-MODEL- 

SINGLE-HANDLER 


SRVCOb-1-THREAD- 

MODEL-SINGLE- 

HANDLER 

SRVOI-THREAD- 

MODEL-MULTIPLE- 

HANDLERS 
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TABLE D-1 DESCRIBES CLIENT AND SERVER-SIDE EXCEPTIONS 
TABLE D-1 ICE-T EXCEPTIONS 



EXCEPTION 


DESCRIPTION 


EXCEPTIONS THROWN BY THE CLIENT PRO! RAM (JAVA CODE): 


PE EXCEPTION 


A GENERAL bAUtr NUN IHAI oloNlribo 
AN UNIDENTIFIED PROBLEM. THE 
MESSAGE MAY INCLUDE MORE DETAILS 
ABOUT WHERE IT WAS RAISED. 
PE~XCEP~ION IS USED VERY RARELY. 


MAP NOT FOUND 
EXCEPTION 


RAISED WHEN A MODULE IN THE 
PRESENTATION ENGINE RECEIVES A 
MESSAGE FOR WHICH NO MAP 
FUNCTION HAS BEEN REGISTERED. THE 
MESSAGE EXPLAINS WHERE AND WHY 
THE EXCEPTION WAS RAISED. 


DiiPUCATE MAP 
EXCEPTION 


RAISED WHEN THE CLIENT PROGRAM 
ATTEMPTS TO REGISTER THE SAME 
MESSAGE IN BOTH THE Ul AND MODEL 


CCMM EXCEPTION 


A GENERAL COMM. EXCEPTION. IT IS 
INDICATES THAT THERE HAS BEEN SOME 
PROBLEM AND PRINTS A MESSAGE WITH 
MORE DETAILS. 


CONNECTION EXCEPTION 


INDICATES THAT THERE WERE SOME 
PROBS IN CONNECTION TO THE SERVER. 


ICE-T PROTOCOL THAT 


PEPROTOCOL EXCEPT. INDICATES THAT 
THERE WAS A PROB. WITH THE IS BEING 
SENT BETWEEN THE CLIENT AND SERVER. 


EXCEPTiONS THROWN BY THE SERVER COMMUNICATION LIBRARY: 


SERVER EXCEPTION 


THE BASE CLASS OF THE OTHER 
EXCEPTIONS. NEVER THROWN. 


SERVER 

COMMUNICATION 
EXCEPTION 


A GENERAL COMM. EXCEPTION. INDICATES 
THAT THERE HAS BEEN SOME COMM. 
PROBLEM AND PRINTS A MESSAGE WITH 
MORE DETAILS 


SERVER 

CONNECTION 

EXCEPTION 


INDICATES THAT THERE IS A PROB. WITH 
THE CONNECTION TO THE CLIENT. IT 
USUALLY INDICATES THAT EITHER THE 
CLIENT HAS SUT DOWN UNEXPECTEDLY 
OR THE CONNECTION HAS TERMINATED. 
AND THE SRVR IS SOMEHOW CONTIN. ON. 


SERVER PROTOCOL 
EXCEPTION 


INDICATES THAT THERE HAS BEEN A 
PROBLEM WITH THE MSG. SENT TO. OR 
RECEIVED FROM. THE CLIENT. EITHER THE 
MSG. TYPE IS UNKNOWN. OR THERE HAS 
BEEN A PROBLEM MARSHALLING OR 
UNMARSHALLING THE DATA. IT MEANS 
THAT SOMEHOW THE BYTES THAT WERE 
SENT ON THE SOCKET WERE GARBLED. 
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